GeezerVison is showing github.com — gh-108223: Add [NOGIL] marker to sys.version by vstinner · Pull Request #108239 · python/cpython
Conversation
vstinner
commented
Aug 21, 2023
•
edited by bedevere-bot
Loading
Uh oh!
There was an error while loading. Please reload this page.
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]
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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]
|
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.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
Can't you use sysconfig.get_config_vars for this?
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
I think changing the format of sys.version warrants a NEWS entry ;)
|
AlexWaygood reacted with thumbs up emoji
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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?
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
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.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
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 :)
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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 reacted with heart emoji
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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 :)
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
|