71–80 of 105 posts
Earlier quoted context omitted.
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.
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.
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.
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.
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.
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.
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.
Earlier quoted context omitted.
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.
Data science, and then ofc DL being done through python just when python 3 was kinda usable (around 3.3/3.4) was a struck of luck timing-wise.
Earlier quoted context omitted.
> JIT in CPython has nothing to do with PyPy or GraalPy: it's its own thing. I haven't said otherwise.
So why did you bring them up…
> So it will join PyPy and GraalPy in the corner.
If you cannot understand what that means, I am not a English professor.
Earlier quoted context omitted.
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.
CL is definitely less dynamic than Python. Dunno about the others.
All of them support changing anything at anytime, killing all JIT assumptions, and forcing it to redo the world.
Stop execution, land into the debugger, change whatever code you feel like during the debugging session and then redo last statement, continuing execution.
There are also ways to do this on fly, without necessarily using the debugger.