Bug report

Bug description:

In a non-free-threading build of Python 3.13, using environment variables or CLI arguments to ensure the GIL is used results in an error:

$PYTHON_GIL=1 python3.13Fatal Python error: config_read_gil: PYTHON_GIL / -X gil are not supported by this buildPython runtime state: preinitialized$python3.13 -Xgil=1Fatal Python error: config_read_gil: PYTHON_GIL / -X gil are not supported by this buildPython runtime state: preinitialized

This is user-hostile behavior that makes it more difficult to write tests and set up test environments. It makes sense thatPYTHON_GIL=0 or-Xgil=0 must fail for non-free-threading builds, but there's no reason why a user requesting that the GIL be enabled in a build where the GIL is always enabled should be an error rather than a no-op.

I bumped into this while working on the test suite forPyStack, where it has forced me into this nasty hack:

@pytest.fixture(autouse=True)defenable_gil_if_free_threading(python,monkeypatch):_,python_executable=pythonproc=subprocess.run([python_executable,"-Xgil=1","-cpass"],capture_output=True)free_threading=proc.returncode==0iffree_threading:monkeypatch.setenv("PYTHON_GIL","1")

instead of what I had originally wanted to do:

@pytest.fixture(autouse=True)defenable_gil_if_free_threading(monkeypatch):monkeypatch.setenv("PYTHON_GIL","1")

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-123275: Support-Xgil=1 andPYTHON_GIL=1 on non-free-threaded builds #123276
• [3.13] gh-123275: Support-Xgil=1 andPYTHON_GIL=1 on non-free-threaded builds (gh-123276) #123753
• gh-123275: Add tests forPYTHON_GIL=1 and-Xgil=1 #123754
• [3.13] gh-123275: Add tests forPYTHON_GIL=1 and-Xgil=1 (gh-123754) #123755