Steve Dower wrote: > 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.
I can agree up to a certain level. There are extensions and there are extensions, see below. > > 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. Ah, hmm, maybe I was not clear enough. I was talking about extensions like itertools or datetime. Not core builtins like sys or the type system. I think, there's a difference. People do use especially the former ones also as a template how things are done "correctly". I agree, it's easy enough to change everything at once, assuming a good test suite :-) Cheers, nd _______________________________________________ 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/ZEYZX7PRCACRZEZIHU35CLWIPHQBALDV/ Code of Conduct: http://python.org/psf/codeofconduct/
