gh-119132: Update sys.version to identify free-threaded or not.

[corona10]

• Issue: Python -VV should display whether the build is default build or free-threading. #119132

[nineteendo]

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) 

[nineteendo]

You still need to update this:

cpython/Lib/platform.py

Lines 1156 to 1161 in 81c3130

	sys_version_parser=re.compile(
	r'([\w.+]+)\s*'# "version<space>"
	r'\(#?([^,]+)'# "(#buildno"
	r'(?:,\s*([\w ]*)'# ", builddate"
	r'(?:,\s*([\w :]*))?)?\)\s*'# ", buildtime)<space>"
	r'\[([^\]]+)\]?', re.ASCII) # "[compiler]"

[nineteendo]

Currently this test is failing:

cpython/Lib/test/test_platform.py

Line 129 in 81c3130

deftest_sys_version(self):

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

[corona10]

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?

[nineteendo]

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] 

[corona10]

@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') 

[vstinner]

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

[vstinner]

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.

[corona10]

Then we need to discuss with @hugovk

[nineteendo]

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.

[corona10]

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

[vstinner]

LGTM, but see my comment on regex.

[miss-islington-app]

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

[bedevere-app]

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

[smontanaro]

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) 

[gpshead]

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.

[smontanaro]

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