Comment by necovek
18 hours ago
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.
> The type of dynamic language gymnastics done with Python is huge
Have you seen Ruby?
Ruby is essentially Smalltalk (see also Objective-C).
I don't know Python's innards well enough to understand why it's so especially difficult in this regard, but I gather around the edges that its object model may not be as well founded.
JIT compiling Ruby or Python in a way that speeds up code using existing libraries and frameworks is harder. We built up decades of code that does stuff that it would be a lot easier for JIT performance if we didn't do, like using C extensions instead of defined FFI.
https://arxiv.org/html/2609.01502v1
The common excuse that ignores Smalltalk, Self, Lisp Machines like Interlisp-D, and more recently Ruby.
All just as dynamic as Python, and with quite usable JIT compilers.
Or for that matter, PyPy and GraalPy do exist.
Obviously, I am not saying making a JIT for Python is impossible: both PyPy and GraalPy prove otherwise. We are talking about full ecosystem support, not just the base language and stdlib.
Can you just replace CPython with PyPy or GraalPy in every project? And why not? :)
Because the Python community writes libraries in C, C++, Fortran and Rust, to make up for the CPython slowness, using CPython C API, calls them Python libraries, and they naturally only work in CPython.
PyPy and GraalPy then never get to use those pseudo "Python" libraries, because their API for C based extensions differs enough that you cannot take a random shared library and load them into either.
They came up with a common C API proposal, but has hardly taken that much adoption.
1 reply →
Operator overloading is a non-issue, it's just another form of method calls.
JavaScript also has monkey-patching, and it's also very common. E.g. SolidJS replaces objects with dependency-tracking proxies.
There are really no fundamental language reasons why Python should be more complex. From what I heard from a JIT developer, the main issue is not the code itself but the module system and code loading.
JavaScript was designed from the start to operate inside a sealed environment with only few external handles, with the code loaded upfront or added on-demand via "eval". Not so for Python, where native code modules can (and will) result in code loaded dynamically and it's hard to track what depends on what.
See Self and Smalltalk for such kind of highly dynamic environment with code being loaded, and completely changing the running image on the fly.
Yet both languages are on the genesis of modern JIT compilers, going beyond what was already being done for Lisps, Prolog, BASIC.
> JavaScript also has monkey-patching, and it's also very common. E.g. SolidJS replaces objects with dependency-tracking proxies.
And the proxies make it slow as Python. Plain objects cannot suddenly become proxies, so the runtime can treat them as a special case.
> Many libraries depend on monkey-patching live library calls, including ones to external dependencies
someone please think of the monkey patchers!