GIL Become Optional in Python 3.13
Python 3.13 is introducing an experimental option to disable the Global Interpreter Lock (GIL), raising hopes for better multicore performance but also concerns about complexity, ecosystem fragmentation, and single‑threaded slowdowns. Commenters debate who truly benefits from a GIL‑less interpreter—high‑performance data and ML workloads versus the large body of simple, single‑threaded code—and worry that this change, along with frequent breaking changes since Python 2→3, may repeat past migration pain. Others argue that Microsoft’s funding and a staged roadmap make a future GIL‑free default likely, with planned optimizations intended to offset most performance regressions.
Performance and semantics of no-GIL Python
- Many are excited that the GIL can be disabled in 3.13, seeing this as overdue and potentially enabling better multicore usage.
- Others stress the theoretical speedup is capped at roughly “current perf × core count,” and real gains will be lower due to synchronization overhead.
- Several comments note that single‑threaded performance may degrade with a thread‑safe interpreter, with some arguing planned optimizations will only “offset” those costs rather than make no‑GIL strictly free.
- There is debate whether no‑GIL will actually benefit most users, vs. a “minority of a minority” who can’t use processes or subinterpreters.
Data science, ML, and concurrency
- Data/ML users highlight big wins from avoiding multiprocessing and large cross‑process copies (e.g., huge dataframes), making simpler multithreaded pipelines attractive.
- Others counter that many numeric workloads already delegate heavy work to C/C++/Fortran and that better algorithmic design often beats parallelism.
- Libraries like pandas could exploit free‑threaded Python internally, but this won’t fix poorly structured user code.
Ecosystem, fragmentation, and compatibility risk
- Strong concern that no‑GIL repeats aspects of the Python 2→3 split, adding a “GIL vs no‑GIL” axis on top of existing async/sync divides.
- Many fear decades of C extensions and libraries written assuming a GIL; these would need auditing or changes.
- Some argue keeping GIL as the default and making no‑GIL optional avoids immediate breakage but risks long‑term ecosystem fragmentation.
Language evolution vs. stability
- Multiple commenters complain Python “changes too much,” citing:
- Removal of standard‑library modules (e.g., distutils) after long deprecation.
- Frequent deprecations and minor incompatibilities across 3.x releases.
- Others argue evolution is necessary for security, new use cases, and platform changes, and that old versions can be kept via version managers, VMs, or containers.
- There is frustration that relying on “system Python” is now fragile, pushing people to tools like pyenv, poetry, uv, asdf, etc.
Typing, JIT, and design direction
- Some want stricter, possibly runtime‑enforced typing (citing mypy pain) or C#/TypeScript‑like ergonomics; others want Python to remain dynamically typed with optional tooling.
- Several mention alternative type checkers (pyright, pyre, pytype) and runtime checkers (e.g., typeguard).
- A side thread debates Python’s lack of a “proper JIT” and compares it unfavorably to historical Lisp systems, though details are contested.