Stefan Behnel wrote: > André Malo schrieb am 14.04.20 um 13:39: > > > I think, it does not serve well as a policy for CPython. Since we're > > talking hypotheticals right now, if Cython vanishes tomorrow, we're > > kind of left empty handed. Such kind of a runtime, if considered part of > > the compatibility "promise", should be provided by the core itself, no? > > > There was some discussion a while ago about integrating a stripped-down > variant of Cython into CPython's stdlib. I was arguing against that because > the selling point of Cython is really what it is, and stripping that down > wouldn't lead to something equally helpful for users. > > I think it's good to have separate projects (and, in fact, it's more than > one) deal with this need. > > In the end, it's an external tool, [...]
Thank you, that is my point exactly. It's the same "external" as everything else. I'm still trying to understand where to separate the different sets of "external". > > > 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. > > I personally see myself using the python-provided runtime (types, methods, > > GC), out of convenience (it's there, so why not use it). The vision of > > the future outlined here can easily lead to backing off from that and > > rebuilding all those things and really only keep touchpoints with python > > when it comes to interfacing with python itself. It's probably even > > desirable that way > > That's actually not an uncommon thing to do. Some packages really only use > Cython or pybind11 to wrap their otherwise native C or C++ code. It's a > choice given specific organisational/project/developer constraints, and > choices are good. Agreed. Nevertheless, the choices are going to be limited by extra constraints. 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/U7KHC7KV5GOOQ4ST5HI3MZKAW4CMRJ6S/ Code of Conduct: http://python.org/psf/codeofconduct/
