Python's experimental JIT to be removed
Python’s core developers have decided to remove the experimental just‑in‑time (JIT) compiler from CPython, citing unclear long‑term maintenance, modest real‑world speedups, and the complexity it adds to a widely used, security‑sensitive runtime. Commenters are split between seeing this as healthy governance that protects stability and tooling compatibility, and as stifling bureaucracy that makes it nearly impossible to land ambitious performance work in the main implementation. Many point to alternatives such as PyPy, GraalPy, Cython, Numba, or wholesale rewrites in faster languages, while lamenting that Python’s ecosystem and C-API quirks make it unusually hard to pair the language’s popularity with state‑of‑the‑art performance.
Overall Reaction to Dropping the JIT
- Many express disappointment; they hoped the JIT would meaningfully speed up “pure Python” and reduce the need for Cython/Rust rewrites.
- Others see the decision as reasonable given modest speedups (often quoted around ~10%) versus large complexity and maintenance burden.
- Some view this as another failed Python JIT attempt (after Psyco, Unladen Swallow, etc.), reinforcing pessimism about CPython ever getting a solid in-tree JIT.
Process, Governance, and “Bureaucracy”
- One camp argues committee process and strict PEP requirements killed an otherwise promising experiment, citing “poison‑pill” requirements like broad tooling support and success metrics.
- Another camp argues the process worked as intended: once something lives on
main, it must have clear scope, maintenance plan, and compatibility story; open‑ended experiments don’t belong in the core of a global infrastructure language. - There’s disagreement over whether this is “bureaucracy” or just necessary governance for a mature ecosystem.
Technical Challenges of a JIT for Python
- Python’s extreme dynamism is cited as a core problem:
__dict__,__class__reassignment, monkey‑patching, metaprogramming, pytest bytecode rewriting, C extensions, and introspection APIs complicate optimization. - Some argue these are not fundamentally harder than JavaScript or Ruby’s semantics and that successful JITs (V8, LuaJIT, PyPy, GraalPy) show it’s feasible with enough investment.
- Others note that CPython’s C API leaks implementation details, making deep changes like JIT and GIL removal especially risky.
Performance Today and Existing Alternatives
- Commonly mentioned options: C extensions, Cython, Numba, mypyc, PyPy, GraalPy, Rust (via PyO3), and Go rewrites.
- Critiques: these are fragmented, each with limitations (version lag, C‑API issues, restricted subsets, deployment complexity). Many still want “just faster CPython.”
- Some argue that Python has hit practical limits: if performance is a core requirement, the answer is to rewrite hot paths or entire systems in faster languages, possibly with AI assistance.
Security and Reliability Concerns
- Some support avoiding a JIT due to security history in JS engines and PHP; they value CPython’s simpler bytecode VM and relatively low CVE count.
- Others respond that Python rarely runs untrusted code, so JIT‑specific exploit risks are less compelling compared to safety problems already introduced by C extensions.
Alternative Directions and Subsets
- Several suggest that a stricter, typed subset of Python with AOT/JIT (e.g., “Static Python”, Mojo‑like, CinderX style) may be the only sustainable path to big speedups.
- There is skepticism that such a subset could be standardized without massive bikeshedding, given Python’s culture and existing dynamic features.