Python 3.12’s new interpreter locks need compatible extensions

The Python 3.12 release, published on October 2, gives developers new ways to divide CPU work and observe running programs. Getting those benefits depends on how applications, native extensions and development tools use the new interfaces.

Official Python logo from the Python Software Foundation, used under its nominative-use policy. Source shapes, colours and shadow are unchanged; proportional rasterization and white padding, with the required accompanying trademark symbol. Python® and the Python logos are trademarks or registered trademarks of the Foundation. Sulat isn’t affiliated with or endorsed by it.

Parallel execution has an isolation boundary

CPython can now create subinterpreters with their own global interpreter locks. Separate interpreters can execute Python code on different CPU cores without competing for the same lock. In 3.12, this capability is exposed through the C API, including Py_NewInterpreterFromConfig. It doesn’t make ordinary threads inside one interpreter execute Python code freely in parallel.

The release-tagged documentation makes the trade-off explicit: independently locked interpreters need their state kept separate. Sharing objects or mutable state between them without thread-safety guarantees can introduce races and crashes. They still inhabit one process and can affect shared resources such as open files, so this isn’t a security sandbox.

Native extensions add another boundary. The isolated configuration requires multi-phase initialization, and the module definition distinguishes support for subinterpreters sharing a lock from support for interpreters with separate locks. An extension working in the normal interpreter doesn’t establish that it supports the new arrangement. The older Py_NewInterpreter entry point retains a shared lock.

Monitoring becomes selective

The new sys.monitoring interface lets debuggers, profilers and coverage tools select execution events and register callbacks. Tools can target individual code objects rather than enabling every event everywhere. For local events, a callback can disable further notifications at a particular location, useful when a coverage tool has already observed it.

Nothing is monitored by default. That makes the change an interface for tool builders to adopt, rather than an automatic acceleration of every existing debugger. PEP 669 describes reduced instrumentation overhead as the goal; callbacks still do work. No independent application benchmark is established by that design.

Installation needs a separate check

The 3.12.0 release notes also remove distutils from the standard library and stop preinstalling setuptools in new venv environments. Projects that import those facilities at runtime need to declare and separately install setuptools instead of assuming it’s present. The notes distinguish this from pip’s isolated build environments, where setuptools can still be supplied for package builds.