The GIL is finally optional in Python 3.13 — does it matter?_

For CPU-bound work Python developers have used multiprocessing for years — separate processes have separate interpreters and no GIL contention. It is more expensive than threads but works today. The no-GIL build makes threads viable as an alternative.

The honest answer is: most web apps are I/O bound. AsyncIO and thread pools already handle concurrency fine for Django and FastAPI. The no-GIL build matters most for scientific computing, video processing, and other CPU-heavy workloads.

CPU-bound multithreaded Python code can now actually run in parallel. Libraries like NumPy that release the GIL during C code already benefited from threading; the change helps pure Python parallelism. Expect async frameworks and scientific computing libraries to be the first to gain.

The Global Interpreter Lock is a mutex that prevents multiple Python threads from executing bytecode simultaneously. It makes the CPython runtime and most C extensions thread-safe by default but means pure Python threads cannot use multiple CPU cores in parallel.