Could we maybe leave out "default" for the normal build? It doesn't really add value:

Python 3.14.0a0 (heads/main-dirty:31a28cbae0, May 17 2024, 17:30:32) [GCC 14.1.1 20240507 (Red Hat 14.1.1-1)]
Python 3.14.0a0 (heads/main-dirty:31a28cbae0, May 17 2024, 17:30:32, free-threading) [GCC 14.1.1 20240507 (Red Hat 14.1.1-1)]

The tests on GitHub don't include "(default)" either. Maybe even like this:

Python 3.14.0a0 (heads/main-dirty:31a28cbae0, May 17 2024, 17:30:32) [GCC 14.1.1 20240507 (Red Hat 14.1.1-1)]
Python 3.14.0a0 (free-threading) (heads/main-dirty:31a28cbae0, May 17 2024, 17:30:32) [GCC 14.1.1 20240507 (Red Hat 14.1.1-1)]

This could even work for --version, but some people might rely on the format:

Python 3.14.0a0
Python 3.14.0a0 (free-threading)

You still need to update this:

Currently this test is failing:

Do you have an opinion on not including "default"?

Do you have an opinion on not including "default"?

Hey, I am under testing. Would you like to leave a comment once I convert the PR into the official PR?

Old regex:

([\w.+]+)\s*\(#?([^,]+)(?:,\s*([\w ]*)(?:,\s*([\w :]*))?)?\)\s*\[([^\]]+)\]?

New regex:

([\w.+]+)\s*\(#?([^,]+)(?:,\s*([\w ]*)(?:,\s*([\w :]*))?)(?:,\s*(free-threading))?\)*\s*\[([^\]]+)\]?

Unmatched string:

2.4.3 (truncation) 
[GCC]

@nineteendo Thanks for the comment

Still issue (nah I am really bad at regex)

- ('CPython', '2.4.3', '', '', 'truncation) \n', '', 'GCC')
?                                         ----

+ ('CPython', '2.4.3', '', '', 'truncation', '', 'GCC')

I proposed a similar idea last August, but it was rejected at that time: #108239

I suggest to mention sys.version in the PR title.

The "(...)" part of sys.version is the Git information, I would prefer to not touch it.

If we change sys.version, I would prefer to "add a new field" in sys.version. For example, add free-threading or [free-threading] after the version. Example:

Python 3.14.0a0 free-threading (heads/main:81c3130c51, May 18 2024, 07:29:44) [GCC 14.0.1 20240411 (Red Hat 14.0.1-0)] on linux

The drawback of changing sys.version is that it breaks tooling parsing it in a strict way.

Then we need to discuss with @hugovk

You accidentally added * after \):

-([\w.+]+)\s*\(#?([^,]+)(?:,\s*([\w ]*)(?:,\s*([\w :]*))?)?(?:,\s*(free-threading))?\)*\s*\[([^\]]+)\]?
+([\w.+]+)\s*\(#?([^,]+)(?:,\s*([\w ]*)(?:,\s*([\w :]*))?)?(?:,\s*(free-threading))?\)\s*\[([^\]]+)\]?

But I would prefer a new field as well.

@Yhg1s What do you think about backporting it into the 3.13 since it will help the free-threading ecosystem?

Thanks @corona10 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

GH-119153 is a backport of this pull request to the 3.13 branch.

Sorry, I haven't been paying close attention, but was there a decision not to tweak sys.version_info as well?

>>> sys.version
'3.14.0a0 experimental free-threading build (heads/main:697465ff88e, May 19 2024, 07:40:21) [Clang 15.0.0 (clang-1500.3.9.4)]'
>>> sys.version_info
sys.version_info(major=3, minor=14, micro=0, releaselevel='alpha', serial=0)

It seems that since it's a named tuple there'd be little problem adding a new field which distinguishes the two builds. Something like:

>>> sys.version_info
sys.version_info(major=3, minor=14, micro=0, releaselevel='alpha', serial=0, free_threading=True)

was there a decision not to tweak sys.version_info as well?

build information is not part of version_info. the version string is meant for humans and includes other detailed things that are also not in version_info such as compiler details.

there's the https://docs.python.org/3.13/library/sys.html#sys._is_gil_enabled may-change-in-the-future API for people wanting to know the current status of the GIL regardless of build type.

Thanks. Just checking. As long as there is somewhere to query the status at run-time without parsing a human-readable string.