Naming the Python binary when `--disable-gil` is set

[personal reply hat, non-SC-voice]

The interpreter executable name is not part of the ABI.

Regardless, we don’t want any OS distros to ship a 3.13 free threading build as an OS package with something in a default $PATH. It is still experimental in this timeframe.

A #! line can happily point to a different installation location of an /opt/py/experimental/free-threading/bin/python binary.

We cannot control distros. They all make their own mistakes. At best I suspect all we can do is just state our expectation up front. Those who go against that know they’re doing a thing we deem wrong and can face social pressure to not be that way.

Why? Long term assume free threaded python is successful exiting experimental phase as we presumably all want. Nobody wants to see an even harder to type interpreter name left lying around as the actual interpreter. when you’re getting down to a full version X.YY specified name maybe it doesn’t matter so much as that isn’t intended to be general, but you’d never want to see a generic unversioned python3-with-blue-sparkles-without-goats-or-wombats unversioned executable.

The existence of things like yum^Wapt install python-is-python3-with-blue-sparkles-without-goats-or-wombats is an anti-pattern.

In effect this defers any potential install naming decision until 3.14 or later once we’ve got some practical knowledge of how things are working out - we’ll presumably know better at that time if there’s a need for parallel installs. It’s okay for some things like this to be decided later, in effect that is why PEP-703 has an Open Issues section not fully specifying this area today.