I didn't notice the current PEP was a provisional one. Hope the new one gets approved. The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
[1] https://fidget-spinner.github.io/posts/jit-on-track.html
Thank You. As someone who don't follow python closely I thought their JIT would be similar to what Ruby has.
Not that Ruby YJIT or ZJIT is anywhere close to what JVM provides, but in this case it seems to be quite far ahead of Python.
Which is surprising given how many major companies are using Python. May be because those using Python are not using it as critical part of work unlike Shopify and Stripe which is their core language?
To leave their experimental phase they have to define some goals to meet and that requires making some architectural choices that still aren't decided.
If I were a contributor I would read such language as saying "we have no respect for you or your intelligence, so we'll just straight up gaslight you and expect you to accept it."
The dictum can't be read literally - it has to be read like the manipulative, narcissist-speak that it is. And what it's telling you is - get out.
> For example, rather than proposing one single concrete JIT implementation,
> it may make more sense for the PEP to describe a JIT infrastructure that
> can support multiple implementation strategies.
> Since many different and promising JIT tracing approaches continue to be proposed,
> we believe the infrastructure should make it easy to experiment with and evaluate
> those approaches within CPython rather than be highly coupled with a single strategy.
out of curiosity, why not?
I mean it seems like they want to get a full spec of what JIT should look like in main? given the faff that hapened with the GC removal, I can sort see why they'd want to do this properly. Especially now that it seems like its practical.
That's a very strong claim. I'm not seeing that at all. What causes you to interpret it that way?
lol
>> For example, rather than proposing one single concrete JIT implementation, it may make more sense for the PEP to describe a JIT infrastructure that can support multiple implementation strategies.
poison-pill requirement
>> We are setting a window of six months for a PEP to be submitted and resolved. If no such PEP is accepted within that window, the JIT code must be removed from the main branch
so it's going to be removed from the main branch
Python JIT history is full of drama, and no, Smalltalk, Common Lisp, Interlisp-D, SELF are just as dynamic if not more.
Er, doesn't that depend on how leaky the abstraction is? How often have you seen a JITted language be unable to swap in a new JITter due to some sort of unintended coupling?
What forever are you talking about? Python removes stuff every single release.
Development hasn't been paused (with negative implications).
It's now considered significant enough that they've requested feature freeze in CPython main until governance/process questions are settled.
If it is, is it not documented somewhere? Maybe as a formal PEP?
If it is not and it is still in heavy experimentation phase (which is fine), it should not be part of the mainline CPython no matter how much more effort it is for the team to experiment with.
They should perhaps have kept it in a separate branch back then, but now is the next best time.
CPython's selling point was that it is simple, fast enough with C extensions and the code was accessible. Complicating the code base for occasional 50% speedups (and regressions ...) just isn't worth it. There are so many other languages that fill that need.
Now, I hope that the PEP does not overpromise again and is accepted because of Instagram pressure. Instagram can keep its own JIT fork or switch to PHP, Go or whatever.
It would be nice if cpython opened up a bit, pluggable GC and JIT would go along way towards reducing this manufactured drama.
It wasn't cool to see PyPy or Stackless getting sidelined.
> pluggable GC and JIT would go along way
One of the points mentioned in the linked discussion is explicitly about ensuring that the JIT design enables multiple implementations.
The flippant attitude of cpythons wrt the standard library is also unfortunate.
Please with your substantive comment comment.
I assume you might mean to ask "why wasn't PyPy adopted in some formal way into CPython" rather than a separate project, for which the answer is at least partially likely to be because it's a completely separate implementation.
At the time I posted it, both were pretty lacking in attention, so it made sense to direct to the earlier of the two.
And yet, I have a hunch it will piss off a lot of people nonetheless and lead to much outrage and wailing and gnashing of teeth. Hopefully it all works out in the long run.
To be fair, the apparent lack of progress of the JIT before was in part due to the same team improving the base interpreter by 40-50% between 3.10 and 3.14. The JIT implementation was pursuing a moving target. It was not some static milestone. Kudos for them.
By now it should be clear to anybody working on Python JIT that the probability of failure is 90%.
The future is probably rewriting performance critical Python code in Rust instead of trying to fix Python.
Or maybe a future LLM could add a JIT to Python in an effort-run.
This will require minor tweaks to the language and perhaps a forked interpreter (a forked parser already exists).
Then you solve the two language problem with a combination of probabilistic and deterministic translation.
As for performance, Python 3.x was not even as fast as Python 2.x in the beginning, but with the correct mindset, it's eventually faster.
I hope they are proud of themselves.
JIT should be a top priority given popularity of Python. It should significantly reduce carbon footprint of Python driven applications.