Compile time. There are preprocessor #if guards all over the code base to provide different implementations for core operations. Many of these are used to provide a thread-safe version (e.g. atomic refcount). Presumably, these should work fine single threaded (assuming correctness). But at the moment they are compile-time, yea.

> With these recommendations and the acceptance of this PEP, we as the Python developer community should broadly advertise that free-threading is a supported Python build option now and into the future, and that it will not be removed without a proper deprecation schedule.

It looks like it still needs to be enabled at compile-time.

> Any decision to transition to phase III, with free-threading as the default or sole build of Python is still undecided, and dependent on many factors both within CPython itself and the community. This decision is for the future.

Compiler flag would be my guess.

You can read the details in PEP 703: https://peps.python.org/pep-0703/

TLDR: Yes.

As of this release, No-GIL/free threading Python has moved out of the experimental phase and is officially supported in this release. No-GIL Python is not the default for this release (that's potentially the next phase of the project), but running no-GIL/free threading is officially blessed.