HN Debrief

Python JIT project was asked to pause development

  • Programming
  • Open Source
  • Developer Tools
  • Infrastructure

The Python steering council said the experimental CPython JIT cannot keep expanding in main without a standards-track PEP that spells out what the JIT is for, what guarantees it makes, how it will be maintained, and how redistributors are supposed to deal with it. The team gets six months to produce and get that proposal accepted. If that does not happen, the JIT code comes out of main. That landed badly because the JIT had only recently reached rough break-even or modest wins against the normal interpreter, after years of chasing a moving target while the base interpreter itself got much faster.

If you depend on CPython internals or care about Python performance, plan around process and maintainability winning over raw momentum. The practical question is no longer just whether the JIT can speed up Python, but whether anyone can define a supportable architecture that core maintainers will own.

Discussion mood

Mostly split but leaning supportive of the steering council. People were frustrated by the timing and worried the move could kill momentum, but the stronger current was that a CPython JIT is too invasive to keep growing in main without a real spec, a maintenance plan, and lessons learned from the recent GC rollback.

Key insights

  1. 01

    Recent GC rollback changed the tolerance for process

    The emergency revert of incremental garbage collection gave people a concrete reason to demand more formality before landing deep runtime changes. The point was not that GC and JIT are technically the same feature. It was that CPython had just seen what happens when interpreter internals change without the governance and review structure a PEP is meant to force.

    Treat this as a governance reset, not an isolated hit on the JIT. Any change that touches interpreter behavior, packaging, or long-term maintenance is likely to face a much higher process bar now.

      Attribution:
    • bob001 #1
    • oefrha #1
    • Retr0id #1
  2. 02

    The JIT was chasing a moving baseline

    The recent performance numbers looked underwhelming in isolation because the baseline interpreter improved dramatically at the same time. That changes how to read the JIT’s apparent lack of progress. A 15 percent gain on top of a much faster CPython is different from five years of standing still, even if many still think the payoff is too small for the added complexity.

    Do not judge interpreter work only by the latest headline speedup over current main. Ask what happened to the baseline during the same period, and whether the project is preserving gains or actually falling behind.

      Attribution:
    • Qem #1 #2
    • IshKebab #1
  3. 03

    Python’s hot paths often live outside CPython

    A lot of Python code either spends its time in C, C++, Rust, NumPy-style native libraries, or waits on I/O. That weakens the business case for a general-purpose CPython JIT compared with ecosystems where application code spends much more time in the language runtime itself. Even the ML case was framed less as executing Python loops faster and more as improving tracing and setup around other JIT systems. Tools like Numba already cover some of the compute-heavy niche.

    If you run a Python-heavy organization, profile before treating the CPython JIT as strategic. Many teams will get more from native extensions, domain-specific accelerators, or startup-path improvements than from a general interpreter JIT.

      Attribution:
    • bob001 #1 #2
    • thatguysaguy #1
    • jbvlkt #1
  4. 04

    PyPy was never a drop-in governance answer

    The repeated “why not just use PyPy” line misses the core constraint. CPython could not simply absorb PyPy without breaking a huge amount of extension compatibility, because the C extension ecosystem is one of Python’s deepest lock-ins. That is why alternative runtimes remain separate implementations instead of obvious successors to CPython.

    If your product depends on Python’s extension ecosystem, assume CPython compatibility will dominate runtime decisions for a long time. Betting on an alternative runtime still means auditing your extension surface, not just swapping interpreters.

      Attribution:
    • kzrdude #1
    • JulianWasTaken #1
  5. 05

    A pluggable JIT could help even if only one ships

    The demand for infrastructure that can support multiple JIT strategies was not only read as sabotage. One commenter with prior work on the idea argued that defining clean seams between the interpreter and the JIT would improve maintainability even if no second JIT ever appears. That reframes “pluggable” from feature creep into an architectural discipline meant to stop the JIT from becoming an unremovable tangle inside the eval loop.

    Watch the eventual PEP for interface boundaries, not just benchmark charts. If those seams are weak, the maintainability objections will remain valid even if the JIT gets faster.

      Attribution:
    • zem #1
    • woodruffw #1
    • germandiago #1
  6. 06

    Maintenance risk got worse after funding losses

    The maintenance argument was not abstract. People pointed out that the JIT effort already lost momentum when Microsoft funding for parts of the Python team went away. A more complicated CPython core is much harder to justify when the pool of paid maintainers is unstable and the feature may depend on a small set of specialists.

    For infrastructure languages, funding and staffing are part of technical feasibility. Before relying on roadmap promises, look at who is actually funded to maintain the feature once the initial champions move on.

      Attribution:
    • kzrdude #1
    • ptx #1

Against the grain

  1. 01

    The new requirements read like a quiet kill shot

    Freezing new work in main right when the JIT began showing progress looked to critics less like governance and more like a way to end the project without saying so. The strongest objection was the request for a broader infrastructure that supports multiple strategies. That sounds prudent on paper, but it also expands scope at exactly the moment a team would normally narrow it and ship.

    If you lead platform work, pay attention to scope changes hidden inside process requests. A demand to generalize architecture before first adoption often means the real fight is over whether the feature should exist at all.

      Attribution:
    • mwkaufma #1
    • sidewndr46 #1
    • _old_dude_ #1
    • mike_hearn #1
  2. 02

    Off-main development is not a harmless workaround

    Several people rejected the softer framing that work can simply continue on a branch. For a change as invasive as a JIT, long-lived divergence from CPython main creates merge debt, semantic conflicts, and eventually a tax big enough to slow or kill the effort anyway. That makes “just develop it elsewhere for now” much less neutral than it sounds.

    When evaluating governance decisions on core systems, distinguish between a paper pause and an engineering pause. If the feature touches too much code, losing access to trunk can materially change its odds of survival.

      Attribution:
    • mellosouls #1
    • wavemode #1
    • baq #1
    • folkrav #1
  3. 03

    Interpreter speed still has an energy cost

    One commenter pushed a view mostly absent elsewhere. Even modest Python speedups matter because the language runs at enormous scale, so interpreter inefficiency translates into real infrastructure and energy waste. That argument does not answer maintainability concerns, but it does challenge the tendency to dismiss a 10 to 20 percent gain as too small to care about.

    If you operate large Python fleets, convert runtime changes into power and infrastructure numbers, not just microbenchmarks. Small per-process gains can still be operationally meaningful at scale.

      Attribution:
    • varispeed #1

In plain english

CPython ↩
The main and standard implementation of the Python programming language, written mostly in C.
eval loop ↩
The core interpreter loop in CPython that reads and executes Python bytecode instructions.
GC ↩
Garbage Collection, automatic memory management that reclaims memory from objects the program no longer uses.
GraalPy ↩
A Python implementation built on GraalVM, a virtual machine platform that can optimize dynamic languages.
I/O ↩
Input and output operations such as reading files, handling network requests, or talking to databases, which often spend time waiting rather than using the CPU.
JIT ↩
Just-in-time compilation, where code is compiled or translated during program execution instead of ahead of time.
JVM ↩
Java Virtual Machine, the runtime that executes Java bytecode and also hosts languages like Clojure.
ML ↩
Machine learning, a branch of artificial intelligence focused on systems that learn patterns from data.
Numba ↩
A Python project that compiles certain numerical Python functions to faster machine code, mainly for array-heavy workloads.
PEP ↩
Python Enhancement Proposal, the formal design document process used to propose and approve major changes to Python.
Pyjion ↩
An experimental project that tried to speed up Python by compiling it with Microsoft’s .NET runtime technology.
PyPy ↩
An alternative Python implementation with its own runtime and a long-running focus on speed, including just-in-time compilation.
Unladen Swallow ↩
A past Google-backed effort to speed up Python using just-in-time compilation based on LLVM.

Reference links

Project and governance posts

Performance and JIT references

  • JIT on track
    Cited as the recent update showing the experimental CPython JIT reaching break-even or modest wins
  • Numba
    Mentioned as an existing way to accelerate some CPU-heavy Python workloads without waiting for a general CPython JIT

Past Python JIT efforts

  • Pyjion
    Named as another attempt to add JIT compilation to Python
  • PEP 3146
    Linked as the proposal associated with Unladen Swallow, a previous attempt to merge JIT-related work into CPython