gh-108223: Add [NOGIL] marker to sys.version

[vstinner]

If Python is configured with --disable-gil, add " [NOGIL]" suffix to sys.version. It should help users to check if they are running a regular Python build with a GIL, or a custom Python build with the new experimental no GIL.

sys.version is commonly requested in bug reports: knowing if Python was configured with --disable-gil should ease debug.

Example on Linux with --disable-gil:

$ ./python -VV Python 3.13.0a0 (heads/main-dirty:d63972e289, Aug 21 2023, 21:43:45) [GCC 13.2.1 20230728 (Red Hat 13.2.1-1)] [NOGIL] 

• Issue: Add --disable-gil option to configure #108223

[vstinner]

The problem of this change is that some scripts rely on the exact sys.version format and parse it with a regular expression or something else.

My previous attempt to add "build information" to sys.version was rejected: #100086 Instead, I modified libregrtest to log "build information": see #108238.

[erlend-aasland]

Can't you use sysconfig.get_config_vars for this?

[erlend-aasland]

I think changing the format of sys.version warrants a NEWS entry ;)

[vstinner]

Can't you use sysconfig.get_config_vars for this?

You mean to leave sys.version unchanged and ask users to dig into sysconfig to check if they are using a NOGIL build or not?

[erlend-aasland]

Can't you use sysconfig.get_config_vars for this?

You mean to leave sys.version unchanged and ask users to dig into sysconfig to check if they are using a NOGIL build or not?

Yes.

[vstinner]

Sure, sysconfig.get_config_var('Py_NOGIL') can be checked.

I'm worried that if tomorrow NOGIL becomes more popular, users may start reporting bugs without even knowing that they use an experimental NOGIL build. Adding a marker to sys.version should help bug triage, but it's an open question. Sure, sys.version can be left unchanged for now.

[erlend-aasland]

I don't think changing the semantics of sys.version is the right solution to that problem though. If we encourage sys.version to be part of a bug report, perhaps a better thing to do would be to add an API for buildinfo (sys.buildinfo?) and encourage users to include also that in their bug reports. For all I know, there may already be such an API :)

[vstinner]

a better thing to do would be to add an API for buildinfo (sys.buildinfo?)

I wrote get_build_info() in test.support.libregrtest.utils for that.

It's hard to decide which build options are relevant to a bug report or not, so I wrote test.pythoninfo which is a giant key-value dump with "everything" :-)

Should we include info which can change how C extensions are loaded? Compiler options? Python ABI? If you get a crash in a third party extension, is it useful to know how it was built? (well, sometimes it is: see this fastmath issue :-)).

I also added sys.thread_info to skip some tests depending on the lock implementation :-)

I don't think changing the semantics of sys.version is the right solution to that problem though

I'm not sure neither, so I close my issue. We can revisit this idea later ;-)

[erlend-aasland]

It's hard to decide which build options are relevant to a bug report or not, so I wrote test.pythoninfo which is a giant key-value dump with "everything" :-)

Exactly; right now, nogil makes sense. In two years time, who knows what makes sense to include :)