Unfortunate. I've been following the work on it occasionally.

On one hand, it seemed like JIT work was really progressing in high gear until SC requested a new PEP. Also unfortunate, as it seemed like part of the hope for the JIT was that it'd counter the performance penalty from free threading.

On the other, it did feel (to me) like with all the fancy (and definitely cool) optimizations it got (automatic refcount operation removal, new type-based specializations, inplace math operations), the macrobenchmark benefits weren't _that_ exciting for a JIT. It definitely has potential for more, maybe with even fancier optimizations like unboxing ints, but the complexity just keeps going up.

> It said that the PEP was "overly optimistic" about user-visible differences with the JIT enabled.

The JIT is technically generated from the same source as the interpreter loop itself, so originally the differences were extremely unlikely, but I imagine the risk just kept going up as new JIT-only paths and optimizations were introduced.

And politically, I feel like SC’s reasoning was just “this side project has landed in main branch almost by accident and has been stewing without oversight ever since, with no stabilization in sight”; and the latest PEP was probably still too vague, with a lot of “here’s more things we can add to the stew” - so I can understand if SC wasn’t satisfied.

Here’s an idea instead (maybe it already exists). Allow a decorator for writing inline Cython. It solves, I think, 90% of the problem. On first run, or eagerly, compile the decorated functions. Basically, Cython is the JIT, and user enables it explicitly.

This way I can easily write inlined functions with proper C speed, in a Python esque language.

Reasons why I rarely use Cython without this:

- unmodified Python code running in Cython is often faster, but not that much. 50% or so is my rule of thumb.

- but the development style is very different for Cython and Python, adding a lot of impedance. Eg reloading doesn’t quite work, profiling is different, you need a build directory and a build step at deployment etc.

- Cython proper is different enough and I’d argue unintuitive enough that if I have to have all these things in place, I might as well wrap my function in Rust.

Such a decorator would give you a low friction way to make things faster when you need it, with scope for making it much faster via all the funny Cython, while keeping Python-esque semantics, in particular "development semantics".

I think it would require some language modification since Cython was definitely a superset of Python; I think some of that syntax has been streamlined, but maybe still a strict superset.

How many Python JIT experiments have failed? I find it interesting because Ruby is probably harder to optimize than Python but Ruby has had a JIT for a long time. Maybe base python is more optimized than base Ruby so the JIT is incrementally not changing much? Also, I'd expect javascript to be harder to optimize but it has JITs. That could just be a funding issue, though. There's probably much more money and incentive to optimize Javascript.

It's unfortunate that a technically exciting new feature is being killed partly because of what is essentially bureaucracy (and the lack of the developer's personal bandwidth). On the other hand, it's pretty safe to say that the strict adherence to the PEP policy and all of the bureaucracy that comes with it is what makes Python a great language, for better or worse.

Not to say that the technical objections were without merit, they likely very much weren't, and the debugger and instrumentation support and maintenance work sounds fairly painful on its own.

If you look at the reasons for this it seems like a good decision: https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to...

There are already many way of addressing Python performance (leaving aside whether Python is a good choice if performance matters) such as Cython, Numba, Pypy and C extensions.

A sad day for CPython but it doesn't have to be a sad day for Python. There is a fully maintained implementation of Python 3.13 that has an advanced JIT compiler. Once your Python warms up it can be 4x faster or higher (depending on what your program is doing). That implementation is called GraalPy and it builds on the JVM:

https://graalpy.org/

A bit like Chrome there's a fully open source version and a proprietary version with a few extra bells and whistles, but the latter is entirely free for both open and commercial usage (you can't redistribute it for a fee). So you may as well use it.

It has other interesting features

• Scalable pauseless GC

• Single binary distribution of Python programs (like Go)

• Fancy and optimized interop with other languages including Java, JavaScript, Kotlin, Ruby and any other Truffle language.

• Supports native extensions. Tested and works with common libs like SciPy, NumPy, PyTorch, Pandas etc: https://graalpy.org/python-developers/compatibility/

• They're working on a GIL-free mode

In recent weeks there has been a release of a new web framework for Python that only runs on GraalPy, called Pyronaut (https://pyronaut.io/). It takes advantage of JVM interop to expose the Micronaut framework, which is similar to Spring for those who know it. Thanks to the JIT and well optimized base libraries it runs extremely fast, being about 3x faster than FastAPI+Granian, or 7x faster than Flask+Gunicorn and having many more features.

https://www.youtube.com/watch?v=zo6L7bxn4OY

(that was presented at Devoxx but the Pyronaut devs will start touring Python specific conferences soon)

So although CPython may not have made it past the JIT milestone, that doesn't mean Python as a language or community has to fail it. It does require openness to alternative implementations, but historically Pythonistas have been fairly good about that (e.g. Pypy was embraced back when it was more active).

This stuff does require you to accept that it's made by Oracle, but as it's open source, that should be OK.

Disclosure: I sit next to some of the people who work on this stuff.

Gonna dump a technical hot take here.

Python is a mature production language with a lot of users. Even before it was huge - like 20 years ago when I was in college - getting a small backwards compatible API change into a python extension module (gnu readline in my case) required convincing GvR personally that the API change was necessary.

Every JIT attempt I've seen for python just tries to cut too deep in the first pass, and scope themselves too large.

I believe any successful attempt at optimizing python performance from JIT will FIRST start with a 100% semantically compatible hidden type model for optimizing object property access and method dispatch.

The single biggest performance delta in most dynamic language jits come from that, not from optimizing guards off of bytecode operations or from compiling to machine code. It's from converting hashtable lookups into constant-time guard + offset lookups.

The hidden type model is also a hard nut to crack. It needs to perserve dict semantics which have very dynamic behaviour via the various `__*__` methods, and handle exotics scope objects since scoped name lookups are the most common ones which have their own exotic behaviours (I remember python providing some ability for callee frames to inspect caller scopes in some limited ways).

This is what happens what the defacto implementation, CPython and its external API, is effectively the specification. That includes all the incidental side effects that were not explicitly designed, but inherited as a quirk of historical implementation. It's next to impossible to retrofit a JIT given these constraints. ECMAScript has a proper specification and several implementations.

> we don't feel we have the personal bandwidth to carry the current version forward

Are the JIT developers the same people who were working on Faster CPython at Microsoft? No surprise that they don't have the same amount of energy to dedicate to the JIT now that it's gone from a full-time job to a hobby project.

The poison-pill requirements had their intended effect: https://discuss.python.org/t/an-announcement-from-the-steeri...

It would have been more honest to just cut the feature instead of haranguing a developer until they withdrew it.

https://github.com/facebookincubator/cinderx might be a better approach.

Surprising, even though (IIRC) the performance of the JIT was always fairly underwhelming.

What about the other major change to Python's implementation: free threading? Has it lived up to expectations? I assume it's not also in doubt, despite Guido recently saying "Personally I wish we’d stuck with the GIL"? [0]

[0] https://discuss.python.org/t/pep-805-safe-parallel-python/10...

1. Python is slow, therefor we use C extensions. 2. We cannot make Python faster because of C extensions. 3. Go to 1.

Sad news, I put a lot of hope in this project. At least we keep the base interpreter improvements they brought along, and we still have PyPy. CPython JIT is dead. Long live PyPy!

It clearly isn't hurting Python's popularity, but man the performance of the reference implementation is embarrassing.

V8 made JavaScript fast in 2008, soon that will be 20 years ago.

Perhaps I live in a bubble, but so much of the production Python code I see is fully type-hinted and makes used of an aggressive linter & type checker to the point where it might as well be written in Go/C#/Java/TypeScript so that it can actually take advantage of the performance gains instead of being loaded into a runtime that turns everything into heap-allocated PyObject pointers.

Sad to read this. I had hoped that with the advance of AI capabilities, features like this could be prototyped, tested, implemented and shipped even faster. And I was really looking forward to see performance gains for my favourite language.

Where do we go from here? Microsoft did not continue to finance the Faster CPython project and the current speed gains are good, but not what we hoped.

From https://discuss.python.org/t/pep-836-jit-go-brrr-the-path-to... :

> We want the PEP to be clear that it’s ultimately the JIT team’s responsibility to find solutions for these packages and tools, and how to deal with situations where a tool can’t be supported or made to work

Is it just me or is this absurdly impossible, to the point of willfully killing the project? Committing a team of brilliant compiler engineers to doing free consulting ad infinitum for every bit of tooling in the world, however hacked-together?

The alternative would be to have the bravery to say: this is the way forward to keep this language relevant into the future, and as a steering committee we collectively own that some tooling may be out of date. Instead, this is a signal that Python is going to rest on its laurels for a very long time.

They should had just port everything to pyPy.

What’s the latest on getting rid of the GIL? Did that work out?

ffffffff.... damnit I love python but why is it so difficult like this. JIT would have been so perfect so the language, increasingly overtime with AI code coming through I am not sure not focusing on making the performance better is going to be better for longer term. Even though a lot of the other operations done in python are done faster in libraries I would still like faster startup times, or faster loops.

This seems to be all about drift from the main implementation of Cpython.

If JIT is different enough in maintenance, security best practices, and consumer use, we don’t have two compilers, we have two different languages.

And that’s the crux of it.

Python needs less features, not more.

What a shame. The alternative is CinderX? It's slower unless you stick to "Static Python" which is not most python code in the wild.

Hope the copy-and-patch work gets a proper write-up before it’s removed... The technique is interesting well beyond CPython.

I hope it does not lead to performance issues later. Python is already famous for being slower than compiled languages.

Python is no doubt a successful language. But, boy - this level of bureaucracy is annoying to no ends. Do people feel eager to propose a PEP? There are so many more enjoyable things to do in one's short life ...

This is why we cannot have nice things.

Why had Python to succeed to Lisp in the AI wave? (rhetoric question)

Since PyPy and GraalPy will never get the love they deserve, I guess there is hope that Julia, Mojo, and the whole Rewrite in Go/Rust keep pushing along then.

I don't know why they don't just adopt Pypy as a faster Python implementation. Just let CPython develop slowly as the reference and give support to Pypy. It is already much faster than CPython.

The Rust based Python3 port can keep it and it can still be far more secure than CPython. Not everything it's JIT'ted on RustPython, it's ondemand per function, you have to enable it explicitly.

Python is a poor target for compilation, even the best JIT is never gonna make fundamental design flaws (that some may consider beloved features) disappear. It's never going to give "good" performance.

In my view, the right course of action is to specify an official strictly typed subset of the language with compilation and static analysis as the justification, then implement both JIT and AOT on top of that. Legacy code can be rewritten or thrown out in phases, C extensions can be ported.

Of course, any such proposal would invite monumental amounts of bikeshedding, which is why it wouldn't get far, much like the JIT proposal.

bureaucracy and politics kills another innovation, fork found in kitchen

Assuming that the biggest bang-for-buck of JIT compilation is optimizing hot loops (which is also the biggest bang-for-buck of optimization in every other context as well), and assuming that, per the historical best practices, all hot loops in Python are already written in C (or Rust, these days), this outcome is somewhat what I would expect.

Interesting, makes sense. JIT in CPython main is a big deal, glad they’re proceeding with caution. Overall looks like they added it as an experimental feature for two years, then decided to back it out. Perfectly reasonable outcome.

what features would need to be removed to help python hit a baseline level of performance? adding typing? Some of the “functional” stuff. Is the performance a legacy issue or essential to the language’s design?

  To me, goals without plans behind them aren't really goals at all

Ok but that's not how specs and plans work -- they are very intentionally two distinct artifacts.

As usual, though, I might just be biased by default towards defending the Python aristocracy; they seem to pretty much always be on the right side of history, even in the little ways!

This is pretty bittersweet to see.

Python is my favorite language, but I'm honestly tired of having to rewrite performance bottlenecks in Cython or Rust all the time. When the Faster CPython project started with Microsoft's backing, I was really excited. Mark Shannon had that plan promising huge speedups across a few cycles, and while that clearly turned out to be much harder than anticipated, the team still kept pushing forward to deliver a real JIT.

Seeing all of that get bogged down in committee bureaucracy now is just frustrating.

I have a lot of respect for the core devs and I know maintaining CPython, and it is a time donation job. It isn't easy. But I feel that over-caution and red tape ends up discouraging serious contributions. They are setting an unreasonably high bar for something that would obviously help the entire ecosystem.

Just think about the sheer amount of electricity and compute power being wasted every single day running inefficient Python across millions of machines worldwide.

Python really deserves a proper JIT. I genuinely hope they reconsider this.

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

This would never have happened with a BDFL

Lol, it seems then they want to have a crippled ecosystem on purpose.

I actually expected something good to come out of this, my mistake for trusting Python "engineers". Never again.

It doesn’t matter. Just write it in Rust. AI will make Python less relevant in the future.

It's strange that typescript has 5 different LLM written competing static translators to compiled languages and python is killing JIT because the PEP was not accepted.

It seems like such a failing and waste of human life that we spend all this time waiting around for python when the JS engines are so cutting edge.

I just use Go and Rust for everything; most of my mobile apps are in Flutter. I don't see any point in using anything else.

for me it's over for python

I would not like a JIT to be embedded in python for one reason. The sole reason why Python didn't have all the security related bugs of other languages (just think about all the exploits in JS engines, as well as the recent PHP vulnerabilities) is sorely because it's an interpreted language, that is python is compiled in a bytecode that runs in a VM.

Under these premises is very difficult that something not implemented correctly is really exploitable, and moreover it's simple to verify the security of the whole thing.

Opening a JIT, that would mean mapping memory pages as RWX, would open the door to all soft of exploits that now are not really possible.