schmeii

There is a flag to enable it, and the default is to run with the GIL.

This pep only affect the C world. It will not require change in Python code.

I don't think that is possible to activate the GIL only for one thread, it has to be activated process-wide.

But, if you want free-threading but you have to use an old extension that is not GIL-less, then you still can, by garding all access to this extension with a lock and setting the PYTHONGIL variable to 0.

But, you will need to compile the extension with --disable-gil or to obtain that from somewhere, if the extension author doesn't provide it, as the ABI of "standard" python and "--disable-gil" python is different.

How --disable-gil builds of python and of extensions will be distributed is not yet totally clear. I don't think pypi has already a clear idea of how to handle those extension, for instance.

Probably in the long-term the two build-mode will be merged and there will only be a "nogil" build-mode.

Which doesn't mean there will be no GIL. Contrary to popular belief the goal of PEP 703 is not to remove the GIL, but only to be able to disable at runtime if you need free threading, so it is an opt-in feature.

In the interim, it seems that Conda have volonteered to build the extensions that are frequently used in the scientific community.

There already is such a mechanism in the pep.

Basically there will be two build mode.

The standard build that you get at python.org will work exactly as now (so with a Gil).

The disable-gil build (which will most likely be available through conda or similar) will have the option to run either with the GIL or without. It will automatically detect extension that are not compatible and switch to Gil mode but you can override this with an environment variable.

That is not true.

If an extension doesn't advertise that it is thread safe, the GIL get activated at runtime so it will work exactly like it does now.