Honorable mention: https://github.com/tonybaloney/Pyjion

Not to forget Unladen Swallow Which even tried to merge into CPython: https://peps.python.org/pep-3146/

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.

My words were

> So it will join PyPy and GraalPy in the corner.

If you cannot understand what that means, I am not a English professor.

I understand your words, I don’t understand why you think they’re relevant to the discussion.

Relegated to niche users, just like the other two.

Except it’s not. The intention of JIT in CPython is to make it into the main branch feature complete. If they can’t get the necessary support then it won’t be relegated to niche uses, it’ll be abandoned and need a new effort to get off the ground.

Not even remotely the same context.

It certainly is the same context, given the Python culture to ignore JITs, rewrite in C, and call it "Python" libraries.

We have been here several times, versus the other dynamic languages, and it has nothing to do with the usual excuse how dynamic Python happens to be.

I don’t know why you keep bringing up Python being dynamic, it’s not particularly relevant. What matters is the content of the request which is to outline how the feature should work and be maintained over time before it can be accepted.

What’s your position? That we should allow an extremely complex system into Python with:

- No clear design goal?

- No maintenance plan?

- No discussion with the steering committee?

PyPy and Jython, and others are not built by the Python team and there has never been a suggestion that any of these systems would be part of CPython.

So again, I still don’t see how different implementations of Python are relevant to the discussion about CPython.

They are relevant for the Python culture towards JIT adoption.

And Ruby

Ruby has not one, two, but three JITs.

Actually more, are you country JRuby, TruffleRuby and RubyMotion.

CL is definitely less dynamic than Python. Dunno about the others.

Why do you think so?

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.