Removing the GIL will not break the vast majority of existing Python code. Here's the backwards compatibility section of PEP 703:

https://peps.python.org/pep-0703/#backwards-compatibility

That section is short and I encourage you to read it in full. Here's what it says about how removing the GIL affects existing Python code:

• Destructors and weak reference callbacks for code objects and top-level function objects are delayed until the next cyclic garbage collection due to the use of deferred reference counting.

• Destructors for some objects accessed by multiple threads may be delayed slightly due to biased reference counting. This is rare: most objects, even those accessed by multiple threads, are destroyed immediately as soon as their reference counts are zero. Two places in the Python standard library tests required gc.collect() calls to continue to pass.

That's it with respect to Python code.

Removing the GIL will require a new ABI, so existing C-API extensions will minimally need to be rebuilt and may also require other changes. Updating C-API extensions is where the majority of work will be if the PEP is accepted.

This will be an opt-in feature by building the interpreter using `--disable-gil`. The PEP is currently targeted at Python 3.13.

This is nothing like the Python 2 > 3 transition.

which python

which python3

which python3nogil

It is not the language’s task to solve. Use a proper dependency manager like nix.

As for managing Python library dependencies, I use poetry (https://python-poetry.org), though unfortunately both it and pipenv seem to progressively break functionality over time for some reason.