Support for free-threading python

[jaraco]

I'd like to see support for launching with free-threaded Python. Probably adding support for -3.13t as a parameter to match with python3.13t.

Currently, it fails thus:

root@fa3030f86adc:/# python3.13t -V
Python 3.13.2
root@fa3030f86adc:/# py -3.13t
Unknown option: -3
usage: /usr/bin/python3.13 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

[brettcannon]

Seems reasonable to me. One thing to decide on is priority selection in a few cases:

• If the newest version of Python is a free-threaded build, do you select it over an older non-free-threaded build?
• If there is a free-threaded and non-free-threaded build for the same version, which do you choose?
• Is there an environment variable that gets exposed to control any of this?

[brettcannon]

@jaraco what's the workflow benefit you're after here? If you're specifying -3.13t, then you could also call python3.13t for the same effect. Is it because you want the automatic .venv usage?

[jaraco]

I'm after the workflow benefits that this project provides.

• Symmetry with Windows Python launcher. I can describe and issue commands that work cross-platform (e.g. py -3.13 -m pip ...).
• Elegance of invocation. py -3.13 separates the concern (run Python) from details about the invocation. py is much easier to type to get a default invocation.
• Flexibility of control. It's possible to set environment variables or update available Pythons and default versions and have invocations evolve alongside (e.g. py -m cowsay always uses the preferred Python).
• Independence from file system. The environment in which a particular invocation occurs doesn't have a dependency on how the installation is laid out or what aliases/symlinks exist. The installations can be pretty-much stock and there's no symlinks to customize or maintain within those installations.
• Virtualenv support.
• Interpreter discovery. Running py --list (or py -0p on Windows) provides a list of the interpreters discovered.

I know I could "not use pylauncher", but that feels like a non-starter for this project.

[jaraco]

I observed today that the Windows Python launcher already has support for free-threaded Python, giving some precedent and answers to the questions above.

• It uses the symbol 3.13t to indicate free-threaded.
• It prefers 3.13t to 3.13.
• The same environment variable PY_PYTHON can be set as before to signal which version.

 ~ 🐚 py -0p
 -V:3.13t *       C:\Program Files\Python313\python3.13t.exe
 -V:3.13          C:\Program Files\Python313\python.exe
 -V:3.12          C:\Python312\python.exe
 ~ 🐚 $PY_PYTHON='3.13'
 ~ 🐚 py -0p
 -V:3.13t         C:\Program Files\Python313\python3.13t.exe
 -V:3.13 *        C:\Program Files\Python313\python.exe
 -V:3.12          C:\Python312\python.exe

It seems to give precedence to x64 over ARM, which seems backwards (the local architecture should be preferred).

 ~ 🐚 py --list
 -V:3.13t *       Python 3.13 (64-bit, freethreaded)
 -V:3.13          Python 3.13 (64-bit)
 -V:3.13-arm64    Python 3.13 (ARM64)

[zooba]

The takeaway here is that users don't like getting experimental (or prerelease) builds by default. So ignore that freethreaded is selected first.

When/if PEP 773 happens, the new launcher implementation will prefer non-freethreaded builds, and as long as Windows ARM64 is experimental it'll also prefer x64 builds.