Because the project has explicitly targeted implementation simplicity, largely successfully, for almost 30 years. The internals are a joy to work on, and unsurprisingly the CPython Git repository has 4x as many contributors as v8, despite CPython contribution being largely voluntary and v8 contribution being largely commercial.
Even if performance were an explicit goal, it's important to remember v8 required absolutely massive funding and top tier engineering support to make it happen at all. The most comparable equivalent in the Python world, PyPy, was the product of an extremely dedicated group of mostly doctoral researchers working against incredible odds. V8 only has 2x as many contributors as PyPy. I hope by now you are recognizing a theme: the reason the language is so successful is also the reason we are here complaining about it.
There have been teams in at least Google and Dropbox who proposed major upheavals of the interpreter in the past. Both failed in large part due to the complexity of their proposals compared to the performance gains on offer
> The most comparable equivalent in the Python world, PyPy, was the product of an extremely dedicated group of mostly doctoral researchers working against incredible odds
"incredible odds" refers to compatibility with the CPython C-extension interface, which is exactly what I'm talking about.
> There have been teams in at least Google and Dropbox who proposed major upheavals of the interpreter in the past. Both failed in large part due to the complexity of their proposals compared to the performance gains on offer
No, they failed because they had to work within the considerable constraints imposed by historically bad decisions (such as the C-extension interface). The proposals need to be complex because they can't break compatibility.
> I hope by now you are recognizing a theme: the reason the language is so successful is also the reason we are here complaining about it.
Not at all! A narrower C-extension interface doesn't imply that C-extensions would be more difficult to write. There are no downsides to a narrower interface (apart from breaking compatibility, but we're positing a world in which this decision was made in 2008 or earlier).
The real theme here is that historical bad decisions + compatibility guarantees add significant complexity to every single improvement if they don't preclude them altogether.
No, it’s not. My comment applies to single threaded performance as well (I wasn’t even thinking about the GIL when I made my comment)—why isn’t Python as fast as modern JS implementations, for example? The answer isn’t “JS has multi thread support”.
Moreover, a slim C extension interface is about flexibility so you don’t paint yourself into a corner when you don’t know what the world might look like tomorrow. Further, you can have a very rich C extension API without exposing the entire interpreter (e.g., h.py). Further still, Python has broken compatibility several times since its inception, so the idea that this was cemented in 91 is nonsense.