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.13
Fatal Python error: config_read_gil: PYTHON_GIL / -X gil are not supported by this build
Python runtime state: preinitialized

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

This is user-hostile behavior that makes it more difficult to write tests and set up test environments. It makes sense that PYTHON_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 for PyStack, where it has forced me into this nasty hack:

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

instead of what I had originally wanted to do:

@pytest.fixture(autouse=True)
def enable_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 and PYTHON_GIL=1 on non-free-threaded builds #123276
• [3.13] gh-123275: Support -Xgil=1 and PYTHON_GIL=1 on non-free-threaded builds (gh-123276) #123753
• gh-123275: Add tests for PYTHON_GIL=1 and -Xgil=1 #123754
• [3.13] gh-123275: Add tests for PYTHON_GIL=1 and -Xgil=1 (gh-123754) #123755