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.
I haven't said otherwise.
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.
Of course the counterargument is that they'll improve it and maybe in future it will be 100% faster... But that seems pretty dubious given the progress so far.
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.
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.
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.
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.
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.
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.
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?
At the time I posted it, both were pretty lacking in attention, so it made sense to direct to the earlier of the two.
I did click on your link, it was a waste of time and that wasn't very nice.
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.
> Please with your substantive comment comment.
I think binning things as drama isn't substantive, particularly when noting about the linked conversation seems dramatic. I also think they're actually talking about the thing you want (pluggable JIT), so the objection seems incongruous.