Re:Python Language Summit: Python Without the GIL
by throwaway894345 on Thursday May 12, 2022 @01:23PM
(#31357123)
You're setting up a dichotomy between a small C-extension interface and code simplicity, but this doesn't make sense. A smaller interface is inherently simpler--it's less for developers to work around, and they can deliver more user value (whether performance or otherwise) per unit complexity.
> 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.
> 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.