GIL Become Optional in Python 3.13

Original Article ↗ Hacker News Discussion ↗

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.