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