Slapping a JIT on Python can't and won't solve it's probblems. Python's problem is that it's semantics make many very important optimizations impossible.
Julia's language semantics were specifically designed to be friendly to JIT optimization. This is something that language devs need to be thinking about very early in the design process or it's hopeless.
The usual argument, yet it works quite well in Languages like Lisp and Smalltalk, both much more dynamic that Python.
At every moment the image can completely change shape, at any given breakpoint I can change anything and then resume execution at a previous point and so on.
I can't say anything about smalltalk since I only played with the VM once and don't know the whole story, but I can think of two reasons why Lisp even though they are more dynamic than Python (for some definition of dynamic) it's easier to JIT.
First is compile-time (macro) and runtime separation, which allows an escape path to move the dynamism out of runtime, so the most powerful transformations doesn't even concern the JIT optimizations (outside of running the macros exactly as described). That's in contrast to R, which is inspired by Lisp like Julia but uses optional lazy evaluation to implement a lot of what a macro can, but it's harder to optimize since the JIT can't just separate and then optimize. And in Python, metaprogramming also requires exploiting heavily runtime tricks (sometimes even considering implementation details of CPython) that then must be properly supported and efficiently executed by any JIT.
Second is cultural, processing power was not abundant when most Lisp dialects were created and became popular, so the ecosystem grows more aware of what dynamism is good and what is bad. Julia is another example, Julia developers since it's release are much more performance aware, so they don't deliberately abuse "Any" containers or type unstable code, eval, runtime function redefinitions and invokelatest, global variables, some types of introspection and other anti-patterns that any JIT built after the fact (decades of libraries later) would have incredible trouble making fast. And in Python, the performance aware people always focused on the FFI instead of restriction the harder to optimize parts of the language, which only made it harder for a Python-only performance solution that can handle this polyglot ecosystem.
It's not an exaggeration to say that billions of dollars and untold man-hours from some of the smartest programmers alive have been spent on trying to make Python faster.
If it was as easy as in Lisp or Smalltalk, don't you think people would have succeeded by now?
Another example worth considering: Javascript is yet another langauge that is arguably more dynamic than Python, yet is rather easy to JIT. What's going on there?
It comes down to the fact that it's not really about the amount of dynamism in a language, but the kinds of dynamism that is really relevant for implementing a JIT compiler.
Personally, (despite, or perhaps due to) Python once being my favorite language, I can't wait. Dynamic typing is too much of a mental strain once you are handed someone else's ML algo code and have to integrate it under tight deadlines.
Though I recently discovered opentelemetry and I'm working on a set of decorators I can use to instrument these monstrosities and figure out what all these rando 5 letter undocumented variables do.
Just FYI, Julia is dynamically typed too. However, I think it is also an existence proof that most of the things people complain about in dynamic languages aren't actually inherent to being a dynamic language.
Julia's language semantics were specifically designed to be friendly to JIT optimization. This is something that language devs need to be thinking about very early in the design process or it's hopeless.