>> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well.
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
No, it’s a simple request to fully investigate the options before committing a massive piece of work to Python. We’ve seen bad implementations of things land before and now live forever. And frankly, if the team can’t pull together a strong maintenance plan, it can’t be allowed to remain in main.
JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing. If they can't get a PEP accepted within 6 months then it's best that the code isn't weighing on the main codebase until an approach can be agreed, at which point work integrating it into main can restart. It's not an all-or-nothing situation.
> For that reason, the Steering Council is formally requesting a Standards Track PEP be authored that the community can discuss and the Steering Council can formally accept (or reject), making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors.
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].
>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
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?
Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.
The python overhead of launching big ML jobs is nontrivial, so I think speeding that up would be meaningful. (I mean the initial tracing and other setup, not things once the GPUs are actually doing the work).
The post clearly says the intention is to get a formal spec for formal integration.
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.
I suspect the recent "we updated the GC without a PEP and it went live and caused massive issues and we need an emergency point release revert" pushed for a greater degree of process overall.
Sure but best case 15% faster clearly isn't worth the complexity of a JIT. It really needs to be at least twice as fast. Pypy pretty much achieves that on average.
Right... but it's still only 15% faster than a simpler alternative. In a language that is 50x slower than the alternatives. Clearly not worth it.
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.
It's effectively a pause. In a project the size of CPython, and a subproject the complexity of a JIT, you can't continue work on a separate branch/repo without guaranteeing that there will be a massive amount of (both textual and semantic) merge conflicts down the road.
"Asked to pause development" isn't entirely accurate: they were asked to pause landing new features (as opposed to bug fixes) on the cPython main branch.
... and only until the whole thing can be fully formalized with an approved PEP. I'm no Python insider, but that doesn't sound horribly controversial to me.
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.
That was kind of overdue. The project started five years ago while massively overpromising.
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.
This hasn't been true for a very long time. Python's major selling points these days are the accessibility of the language and the extensive ecosystem. A vanishingly small fraction of users ever look at the implementation internals. Telling people "if you don't like it, switch to a different language" is particularly unhelpful because rewrites are rather famously expensive. Making things more complicated for the few maintainers, so that they work better for the millions of users, is easily a worthwhile tradeoff.
Who is going to pay for maintaining the massively more complicated implementation though? Microsoft pulled their funding of the Python team, and even if they hadn't I think there' a danger in making Python so complicated that it collapses under its own weight without the continued support of some giant corporation.
What a shame it will receive a halt when they where starting to make progress I know that after submitting the pep it will go back to development. But t would have been better to just keep the development and the pep for an actual release or continue and if gets rejected ask them to stop
> What a shame it will receive a halt when they where starting to make progress I know that after submitting the pep it will go back to development.
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.
This isn't really a substantive comment, and to at least one extent it's trivially falsifiable (15 years is before Python 3 became usable, so that alone is a "serious" change in the language).
> 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.
It seems to have been serious enough; I don't think Python would have succeeded as a language if they hadn't done Python 3.
> 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.
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.
The short answer is that CPython didn't want to break compatibility with lots and lots and lots of Python modules implemented in C, so it was never viable to let PyPy seamlessly replace CPython.
People in this thread writing conspiracy theories over the biggest language in the world requiring a bit of bureaucracy lends some credence to the idea that programming is not real engineering.
> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well.
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.
I agree.
And the next section is very clear that they want to kill the project.
> 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.
Allowing multiple strategies is far harder and as far as I know, JIT tracing is still unproven.
I suspect there were people who had alternative proposals which got implicitly blocked by this 5 year effort. Letting a subgroup run wild without proper process is not good for a project this large.
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.
It's because they say they don't want to call for competitors and then immediately do so in the second half of the same sentence. It probably wasn't written with bad intent, but you can see why people might find it a strange choice.
Losing development momentum for a beancounting reason like this one is a sure way to kill a project. It works every time. Once development is halted, it is very difficult to pick it back up.
Python isn't a side project to yolo on. Updating the GC without a PEP caused massive issues for actual people using Python. If you want to impact software used by millions of developers then you better be willing to handle a bit of process.
It would make sense if there was any activity on that older post. A 12 hour old post with no comments is dead, linking to it is a waste of time, especially for those who click on it to find 0 comments.
I did click on your link, it was a waste of time and that wasn't very nice.
>> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well.
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
No, it’s a simple request to fully investigate the options before committing a massive piece of work to Python. We’ve seen bad implementations of things land before and now live forever. And frankly, if the team can’t pull together a strong maintenance plan, it can’t be allowed to remain in main.
So it will join PyPy and GraalPy in the corner.
Python JIT history is full of drama, and no, Smalltalk, Common Lisp, Interlisp-D, SELF are just as dynamic if not more.
JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing. If they can't get a PEP accepted within 6 months then it's best that the code isn't weighing on the main codebase until an approach can be agreed, at which point work integrating it into main can restart. It's not an all-or-nothing situation.
> JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing.
I haven't said otherwise.
And Ruby
> For that reason, the Steering Council is formally requesting a Standards Track PEP be authored that the community can discuss and the Steering Council can formally accept (or reject), making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors.
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
>The experimental JIT was reported to finally breaking even and surpassing the default interpreter just a couple of months ago[1].
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?
Python software is to a large extent either doing things in not-python (c, c++, rust, etc.) or doing things that are not cpu bound (io bound, async, etc.). If you're cpu bound then you can either take a 2x jit improvement or take a 10x non-python improvement. There's few companies of a scale where the non-hot path cost of 2x cpu is so massive as to be worth caring about.
The python overhead of launching big ML jobs is nontrivial, so I think speeding that up would be meaningful. (I mean the initial tracing and other setup, not things once the GPUs are actually doing the work).
Also you can use projects like numba https://numba.pydata.org/
Kind of a shit move to suddenly pull the rug once they've finally gotten it working. Should have been kept out of main from the start.
The post clearly says the intention is to get a formal spec for formal integration.
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.
I suspect the recent "we updated the GC without a PEP and it went live and caused massive issues and we need an emergency point release revert" pushed for a greater degree of process overall.
Sure but best case 15% faster clearly isn't worth the complexity of a JIT. It really needs to be at least twice as fast. Pypy pretty much achieves that on average.
15% faster on top of a base interpreter that itself got 40%-50% faster on the same timeframe.
Right... but it's still only 15% faster than a simpler alternative. In a language that is 50x slower than the alternatives. Clearly not worth it.
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.
Editorialised title.
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.
It's effectively a pause. In a project the size of CPython, and a subproject the complexity of a JIT, you can't continue work on a separate branch/repo without guaranteeing that there will be a massive amount of (both textual and semantic) merge conflicts down the road.
Nah, you just merge main back every day or so.
"Asked to pause development" isn't entirely accurate: they were asked to pause landing new features (as opposed to bug fixes) on the cPython main branch.
... and only until the whole thing can be fully formalized with an approved PEP. I'm no Python insider, but that doesn't sound horribly controversial to me.
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.
Sounds reasonable given the recent YOLO GC debacle https://discuss.python.org/t/reverting-the-incremental-gc-in....
That seems entirely unrelated?
That was kind of overdue. The project started five years ago while massively overpromising.
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.
This hasn't been true for a very long time. Python's major selling points these days are the accessibility of the language and the extensive ecosystem. A vanishingly small fraction of users ever look at the implementation internals. Telling people "if you don't like it, switch to a different language" is particularly unhelpful because rewrites are rather famously expensive. Making things more complicated for the few maintainers, so that they work better for the millions of users, is easily a worthwhile tradeoff.
Who is going to pay for maintaining the massively more complicated implementation though? Microsoft pulled their funding of the Python team, and even if they hadn't I think there' a danger in making Python so complicated that it collapses under its own weight without the continued support of some giant corporation.
What a shame it will receive a halt when they where starting to make progress I know that after submitting the pep it will go back to development. But t would have been better to just keep the development and the pep for an actual release or continue and if gets rejected ask them to stop
> What a shame it will receive a halt when they where starting to make progress I know that after submitting the pep it will go back to development.
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 have used Python as my main language since the late 90s and it has been over the last decade and half been getting more unserious.
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.
This isn't really a substantive comment, and to at least one extent it's trivially falsifiable (15 years is before Python 3 became usable, so that alone is a "serious" change in the language).
> 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.
Python 2 to 3 transition was also unserious.
The flippant attitude of cpythons wrt the standard library is also unfortunate.
Please with your substantive comment comment.
It seems to have been serious enough; I don't think Python would have succeeded as a language if they hadn't done Python 3.
> 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.
Why was PyPy abandoned and not embraced by Python? NIH?
(PyPy was not abandoned.)
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.
The short answer is that CPython didn't want to break compatibility with lots and lots and lots of Python modules implemented in C, so it was never viable to let PyPy seamlessly replace CPython.
There is a large graveyard of JITs and JIT-adjacent projects for Python.
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.
People in this thread writing conspiracy theories over the biggest language in the world requiring a bit of bureaucracy lends some credence to the idea that programming is not real engineering.
Seems reasonable. As I understand it the JIT implementation has not really been successful anyway.
> While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well.
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.
I agree. And the next section is very clear that they want to kill the project.
Allowing multiple strategies is far harder and as far as I know, JIT tracing is still unproven.I think this is uncharitable, it's not like they're inventing new requirements that weren't there before. The PEP process has existed the whole time.
I suspect there were people who had alternative proposals which got implicitly blocked by this 5 year effort. Letting a subgroup run wild without proper process is not good for a project this large.
> The dictum can't be read literally
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.
"it has to be read like the manipulative, narcissist-speak that it is"
That's a very strong claim. I'm not seeing that at all. What causes you to interpret it that way?
It's because they say they don't want to call for competitors and then immediately do so in the second half of the same sentence. It probably wasn't written with bad intent, but you can see why people might find it a strange choice.
Losing development momentum for a beancounting reason like this one is a sure way to kill a project. It works every time. Once development is halted, it is very difficult to pick it back up.
Python isn't a side project to yolo on. Updating the GC without a PEP caused massive issues for actual people using Python. If you want to impact software used by millions of developers then you better be willing to handle a bit of process.
They're not being asked to halt development, they're being asked to halt landing new features on the cPython main branch.
The JIT project already lost a lot of momentum when the people working on it lost their jobs (at Microsoft)..
Duplicate of here:
https://news.ycombinator.com/item?id=48421400
Don't bother clicking, that post got 0 attention. Not helpful, mate.
It is literally the same link, it was the original and it had the correct title rather than the editorialised one here.
At the time I posted it, both were pretty lacking in attention, so it made sense to direct to the earlier of the two.
It would make sense if there was any activity on that older post. A 12 hour old post with no comments is dead, linking to it is a waste of time, especially for those who click on it to find 0 comments.
I did click on your link, it was a waste of time and that wasn't very nice.