That’s actually the Bureau of Engraving and Printing, on 14th St. SW, which is indeed worth visiting. They print the paper bills (among other things). The U.S. Mint produces the coins. I think only the Philadelphia Mint still mints coins, but it’s also worth visiting.

Denver also mints coins for circulation (mint mark D) and San Francisco does rarely, but mostly does proof sets (legal tender, but generally kept by collectors). Apparently there’s also a newer mint at West Point which uses a W mint mark and also mints coins for circulation.

You can (and should!) tell pip not to do this with '--only-binary=:all:'. Building from source is a lousy default.

Requiring increasingly long arcane incantations in the name of backwards compatibility is a terrible design philosophy and introduces security fatigue. Most users will not use aliases, and it's poor security posture to ask them to.

Given how often the python community already deals with breaking changes, it shouldn't be much different for pip to adopt saner defaults in a new major version.

While I agree, pip has very strong backward compatibility requirements. I'm not sure why, maybe because people tend to upgrade it without considering the consequences.

For what it’s worth, I was in the “loved it” camp.

(I’m the author of dataclasses, and I owe an immeasurable debt to Hynek).

Thank you for creating dataclasses!

And for a similar idea in Python see https://peps.python.org/pep-0750/

I think you're saying that it takes fewer characters to define a namedtuple. If you're interested in less typing, There's also dataclasses.make_dataclass:

   >>> Point = dataclasses.make_dataclass("Point", ["x", "y", "z"])
   >>> Point(1, 2, 3)
   Point(x=1, y=2, z=3)

This is incorrect. The returned integer is a regular Python object, not some "unboxed" integer value.

What you're seeing here is an optimization about integers, not about pass by value. CPython only does this for small integers:

  $ python -c "print(int('3') is int('3'))"
  True
  $ python -c "print(int('300') is int('300'))"
  False

Other implementations make different choices.

I’ve worked at places where subverting firewall rules like this would get you fired. I now refer to such situations where I’m forced to twiddle my thumbs while no work gets done as “letting the process work”.

I always kick this kind of decision upwards: we can do it this way and break this rule, so I need director level approval, or we can wait until the customer blinks.

Yes. Ask your boss for approval and tell them otherwise nothing will get done.

This is spelled out in the PEP (I’m the author). There isn’t one “portion” (a term defined in the PEP) to own that file. And it’s also not a requirement that all portions be installed in the same directory. I’m sorry you feel this was lazy, it was a lot of work spanning multiple attempts over multiple years.

I appreciate your work on pep 420; I’ve benefited from it personally as a Python user. Thank you for a job well done.

Thank you for the kind words.

> JavaScript tooling requires index files for everything

This just isn't true. I've never encountered tooling that forces you to have these by default. If it's enforced, it's rules defined in your project or some unusual tools

What do you mean by index files? It might depend on the bundler, but I haven’t heard of index.js/index.ts files being a hard requirement for a directory to be traversable in most tooling.

> JavaScript tooling requires index files for everything

You mean barrel files? Those are horrible kludges used by lazy people to pretend they're hiding implementation details, generate arbitrary accidental circular imports, and end up causing absolute hell if you're using any sort of naive transpiling/bundling tooling/plugin/adapter.

For managing config files I use yadm https://yadm.io/, which I learned of on HN.

Among other great features, it lets me tailor settings per OS (Windows, Mac, Linux) and per client. And my settings are all in git, so they’re easy to save and copy around, and they’re all in one place, not dependent on each tool to know how to save their settings on some server.

Have you used Chezmoi (https://chezmoi.io) before? I've been using that for a few years now; I'd be curious to understand how YADM compares.

I have not used chezmoi, thanks for the pointer. From the comparison chart it looks similar to yadm. It looks like go vs. bash is the biggest difference. It’s occasionally handy to debug yadm’s bash script, although it’s been years since I had to do so. I’ll take a deeper look.

A major reason I stick with yadm, aside from that it works great and offers me no trouble, is that for basic usage I can just reuse my existing familiarity with the git interface, replacing "git" with "yadm" in the command.