Python 3.13 Gets a JIT

JIT = "just in time" = bytecode is converted to native code while the program is running, either at the startup of the program or just before a particular function is called. Sometimes even after the function is called (since the JIT process itself takes time, it may be optimal to only run it once a function has been called N times or taken M microseconds total run time)

AOT = "ahead of time" = bytecode is converted to native code before the program starts. i.e. by the developer during their distribution or deployment process. AOT compilation knows nothing about the specific run time conditions.

Not pursuing JIT or efficient compilation in general was a deliberate decision way back when Python made some kind of sense. It was the simplicity of implementation valued over performance gains that motivated this decision.

The mantra Python programmers liked to repeat was that "the performance is good enough, and if you want to go fast, write in C and make a native module".

And if you didn't like that, there was always Java.

Today, Python is getting closer and closer to be "the crappy Java with worse syntax". Except we already have that: it's called Groovy.

Maybe Microsoft don't know yet how to sell this thing, or maybe they are just boiling the frog. Time will tell. But I'm pretty sure your question will be repeated as soon as people will get used to the idea of Python on JIT.

The package management and build tools for python have been so atrociously bad (environments add far too much complexity to the ecosystem) that it turns many developers away from the language altogether. A system like Rust's package management, build tools, and cross compilation capability is an enormous draw, even without the memory safety. The fact that it actually works (because of the package management and build tools) is the main reason to use the language really. Python used to do that ~10 years ago. Now absolutely nothing works. It takes weeks to get simple packages working, only can do anything under extremely brittle conditions that nullify the project you're trying to use this other package for, etc.

If python could ever get it's act together and make better package management, and allow for cross-compiling, it could make a big difference. (I am aware of the very basic fact that it's interpreted rather than compiled yada yada - there are still ways to make executables, they are just awful). Since python is data science centric, it would be good to have decent data management capabilities too, but perhaps that could be after fundamental problem are dealt with.

I tried looking at mojo, but it's not open source, so I'm quite certain that kills any hope of it ever being useful at all to anyone. The fact that I couldn't even install it without making an account made me run away as fast as possible.