Hacker News
points by necovek 2 days ago | 0 comments
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.
[–] xorcist 2 days ago
> The type of dynamic language gymnastics done with Python is huge

Have you seen Ruby?

[–] KerrAvon 2 days ago
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.

[–] jashmatthews 2 days ago
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

[–] pjmlp 2 days ago
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.

[–] cdavid 1 day ago
The common excuse is indeed wrong, as pypy proved. IMO the real issue is the python C API.

The python C API is the "killer app" of python, and what gave its edge against otherwise similar languages (ruby/js). That's makes it unique (the whole scientific stack). But a lot of early choices leaked into this API, and this (+ preference from guido for simple implementation) is at odds with doing JIT: lots of global state (instead of explicitly passing interpreter state), ref counting, no tagged pointers meaning boxing/unboxing everywhere, etc. Some of those are getting gradually fixed, but that's a slog, though maybe AI can accelerate a lot.

I had high hopes for HPy but that unfortunately fizzled out.

[–] necovek 2 days ago
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? :)

[–] pjmlp 2 days ago
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.

[–] necovek 2 days ago
Indeed, mixing all the language features and anti-features with non-native Python libraries is a big reason too — both because it mitigates many of the performance issues a JIT would solve, but mostly because it complicates or makes the implementation unfeasible altogether.
[–] cyberax 2 days ago
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.

[–] pjmlp 2 days ago
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.

[–] exyi 2 days ago
> 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.

[–] mistrial9 2 days ago
> Many libraries depend on monkey-patching live library calls, including ones to external dependencies

someone please think of the monkey patchers!