Feature Description

• Displayed version by pdm python list should display threaded tag t
  • This is especially useful as pdm python remove command will also require the t tag
• Threaded Python should be considered as a separate option and should not be preferred (until it's default and not tagged
  • Threaded version is tagged for a reason, it is still experimental and will have compatibility issues.
• User should have the ability to specify if threaded python should be used or preferred

Problem and Solution

Issue 1: Currently PDM does not display free threaded versions as a different version:

PS [REDACTED]> pdm python list
cpython@3.13.3 ([REDACTED]\pdm\python\cpython@3.13.3t\install\python.exe)
cpython@3.13.4 ([REDACTED]\pdm\python\cpython@3.13.4\python.exe)
cpython@3.13.4 ([REDACTED]\pdm\python\cpython@3.13.4t\install\python.exe)
PS [REDACTED]> pdm python remove cpython@3.13.4
Removed installed cpython@3.13.4
PS [REDACTED]> pdm python list
cpython@3.13.3 ([REDACTED]\pdm\python\cpython@3.13.3t\install\python.exe)
cpython@3.13.4 ([REDACTED]\pdm\python\cpython@3.13.4t\install\python.exe)
PS [REDACTED]> pdm python remove cpython@3.13.4
ERROR: No Python interpreter found for 'cpython@3.13.4'
Installed Pythons:
  cpython@3.13.3t
  cpython@3.13.4t

Issue 2: Installing Python >=3.13 will automatically pick cpython 3.13t as the higher available version

PS [REDACTED]> pdm python install
⠴ Downloading cpython@3.13.4t
⠴ Installing cpython@3.13.4t
Successfully installed cpython@3.13.4
Version: 3.13.4
Executable: [REDACTED]\pdm\python\cpython@3.13.4t\install\python.exe

Issue 3: Specifying free-threaded versions using cpython version format is not supported

PS [REDACTED]> pdm python install
[InvalidPyVersion]: Invalid specifier: >=3.13,!=3.13.4t

This together with issues caused by incompatibilities between free-threaded and GIL variants will require attention.

@frostming already added this flag and it seems reasonable to expand the support this way. PythonVersion already treats t tag as not matching version.

I am not sure about adding t tag to requires-python as it is against versioning RFC but if everyone already went this way, it seems to be the most intuitive approach.

Additional Context

From Python 3.13 there are specific free-threaded releases marked like 313t or cpython@3.13.4t
The problem of multiple versions was vaguely mentioned in PEP-703

This PEP poses new challenges for distributing Python. At least for some time, there will be two versions of Python requiring separately compiled C-API extensions. It may take some time for C-API extension authors to build --disable-gil compatible packages and upload them to PyPI. Additionally, some authors may be hesitant to support the --disable-gil mode until it has wide adoption, but adoption will likely depend on the availability of Python’s rich set of extensions.

In 2024, CPython 3.13 is released with support for a --disable-gil build time flag. There are two ABIs for CPython, one with the GIL and one without. Extension authors target both ABIs.
After 2–3 releases, (i.e., in 2026–2027), CPython is released with the GIL controlled by a runtime environment variable or flag. The GIL is enabled by default. There is only a single ABI.
After another 2–3 release (i.e., 2028–2030), CPython switches to the GIL being disabled by default. The GIL can still be enabled at runtime via an environment variable or command line flag.

There are already some problems related to supporting two versions like linking to 313t.lib

PEP-703 specifies build configuration change:

When built with --disable-gil, CPython will define the Py_GIL_DISABLED macro in Python/patchlevel.h. The ABI tag will include the letter “t” (for “threading”).

Additional context:
platform compatibility tags
Include "t" in ABI tag for --disable-gil builds

Are you willing to contribute to the development of this feature?

• Yes, I am willing to contribute to the development of this feature.