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.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RFYAK5NDBY4DYHKBYOQK5SUKMIT4VZZX/
Code of Conduct: http://python.org/psf/codeofconduct/
