Steve Dower schrieb am 14.04.20 um 00:27: > On 13Apr2020 2308, André Malo wrote: >> For one thing, if you open up APIs for Cython, they're open for everybody >> (Cython being "just" another C extension). >> More to the point: The ABIs have the same problem as they have now, >> regardless >> how responsive the Cython developers are. Once you compiled the extension, >> you're using the ABI and are supposedly not required to recompile to stay >> compatible. >> >> So, where I'm getting at is: Either you open up to everybody or nobody. In C >> there's not really an in-between. > > On a technical level, you are correct. > > On a policy level, we don't make changes that would break users of the C > API. Because we can't track everyone who's using it, we have to assume that > everything is used and any change will cause breakage. > > To make sure it's possible to keep developing CPython, we declare parts of > the API off limits (typically by prepending them with an underscore). If > you use these, and you break, we're sorry but we aren't going to fix it. > > This line of discussion is basically saying that we would designate a > broader section of the API that is off limits, most likely the parts that > are only useful for increased performance (rather than increased > functionality). We would then specifically include the Cython > team/volunteers in discussions about how to manage changes to these parts > of the API to avoid breaking them, and possibly do simultaneous releases to > account for changes so that their users have more time to rebuild. > > Effectively, when we change our APIs, we would break everyone except Cython > because we've worked with them to avoid the breakage. Anyone else using it > has to make their own effort to follow CPython development and detect any > breakage themselves (just like today). > > So probably the part you're missing is where we would give ourselves > permission to break more APIs in a release, while simultaneously > encouraging people to use Cython as an isolation layer from those breaks.
To add to that, the main difference for users here is a choice: 1) I want to use whatever is in the C-API and will fix my broken code myself whenever there's a new CPython release. 2) I write my code against the stable ABI, accept the performance limitations, and hope that it'll "never" break and my code just keeps working (even through future compatibility layers, if necessary). 3) I use Cython and rerun it on my code at least once for each new CPython release series, because I want to get the best performance for each target version. 4) I use Cython and activate its (yet to be completed) stable ABI mode, so that I don't have to target separate (C)Python releases but can release a single wheel, at the cost of reduced performance. And then there are a couple of grey areas, e.g. people using Cython plus a bit of the C-API directly, for which they are then responsible themselves again. But it's still way easier to adapt 3% of your code every couple of CPython releases than all of your modules for each new release. That's just the normal price that you pay for manual optimisations. A nice feature of Cython here is that 3) and 4) are actually not mutually exclusive, at least as it looks so far. You should eventually be able to generate both from your same sources (we are trying hard to keep them in the same C file), and even mix them on PyPI, e.g. distribute a generic stable ABI wheel for all Pythons that support it, plus accelerated wheels for CPython 3.9 and 3.10. You may even be able to release a pure Python wheel as well, as we currently do for Cython itself to better support PyPy. And to drive the point home, if CPython starts changing its C-API more radically, or comes up with a new one, we can add the support for it to Cython and then, in the best case, users will still only have to rerun it on their code to target that new API. Compare that to case 1). > (Cython is still just a placeholder name here, btw. There are 1-2 other > projects that could be considered instead, though I think Cython is the > only one that also provides a usability improvement as well as API > stability.) pybind11 and mypyc could probably make a similar offer to users. The important point is just that we centralise the abstraction and adaptation work. Stefan _______________________________________________ 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/BHH3XKTCKZ73WQNHPVHYNBMJPYBELZFV/ Code of Conduct: http://python.org/psf/codeofconduct/
