On 14Apr2020 1557, André Malo wrote:
Stefan Behnel wrote:
André Malo schrieb am 14.04.20 um 13:39:
A good way to test that promise (or other implications like performance) might
also be to rewrite the standard library extensions in Cython and
see where it leads.
Not sure I understand what you're saying here. stdlib extension modules are currently written in C, with a bit of code generation. How is that different?
They are C extensions like the ones everybody could write. They should use the same APIs. What I'm saying is, that it would be a good test if the APIs are good enough (for everybody else). If, say, Cython is recommended, some attempt should be made to achieve the same results with Cython. Or some other sets of APIs which are considered for "the public".
I don't think, the current stdlib modules restrict themselves to a limited API. The distinction between "inside" and "outside" bothers me.
It should not bother you. The standard library is not a testing ground for the public API - it's a layer to make those APIs available to users in a reliable, compatible format. Think of it like your C runtime, which uses a lot of system calls that have changed far more often than libc.
We can change the interface between the runtime and the included modules as frequently as we like, because it's private. And we do change them, and the changes go unnoticed because we adapt both sides of the contract at once. For example, we recently changed the calling conventions for certain functions, which didn't break anyone because we updated the callers as well. And we completely reimplemented stat() emulation on Windows recently, which wasn't incompatible because the public part of the API didn't change (except to have fewer false errors).
Modules that are part of the core runtime deliberately use private APIs so that other extension modules don't have to. It's not any sort of unfair advantage - it's a deliberate aspect of the software's design.