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