The type of dynamic language gymnastics done with Python is huge: any sufficiently well known library basically employs some sort of meta-programming of the language:

  * Typing is a non-obligatory add-on to the syntax
  * SQLAlchemy and other ORMs override basic operators like "=" and employ metaclass programming heavily to create Python-like SQL query builders
  * Pytest rewrites all the assertions as it side-steps bytecode generation (so your .pyc files are different than what they would be without pytest)
  * Many libraries depend on monkey-patching live library calls, including ones to external dependencies
  * The way async was added in is another bolt-on where the same code behaves differently in different contexts
  * Decorators can introduce any side-effect you imagine, and nobody (including core libraries) follow the golden rule of "don't do, only decorate"
  * Many debugging and profiling mechanisms (including REPL) depend on these properties to function — including observability tooling like Sentry, Datadog etc.
  ...

JavaScript never had that level of flexibility (for better and for worse), and by extension, it's easier to build an alternative implementation and keep it compatible with the rest of the world that claims to be JavaScript.

> How many Python JIT experiments have failed?

Wait, how many? I'd say just this one. The other that I know of, pypy, was massively successful for a single maintainer project. And definitely showed the possibility/potential of JIT python.

I wouldn't call it a failure for not over taking mainline CPython.

Python is harder to JIT because of the way __dict__ works.

If all python had was __slots__ then we would not be struggling to JIT python.

Tight numerical loops is where the JIT adds performance.

Most performance sensitive features are already available in python between numpy, numba and Cython without really leaving the language core.

You'll mostly be speeding up the slow parts of python, not supercharging the fast parts.

    >>> class Dog:
    ...     def hi(self):
    ...             print("woof")
    ...
    >>> class Cat:
    ...     def hi(self):
    ...             print("meow")
    ...
    >>> dog = Dog()
    >>> dog.hi()
    woof
    >>> dog.__class__ = Cat
    >>> dog.hi()
    meow
    >>> isinstance(dog, Dog)
    False
    >>> isinstance(dog, Cat)
    True
    >>>

    >>> Dog.__bases__ = (Cat,)
    >>> isinstance(dog, Dog)
    True
    >>> isinstance(dog, Cat)
    True
    >>>

> Maybe base python is more optimized than base Ruby

Not since before Ruby 1.9, no.