> On 15 Jun 2018, at 13:00, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 14 June 2018 at 06:30, Ronald Oussoren <ronaldousso...@mac.com > <mailto:ronaldousso...@mac.com>> wrote: >> On 13 Jun 2018, at 15:42, Nick Coghlan <ncogh...@gmail.com >> <mailto:ncogh...@gmail.com>> wrote: >> >> Yeah, pretty much - once we can get to the point where it's routine for >> folks to be building "abiX" or "abiXY" wheels (with the latter not actually >> being a defined compatibility tag yet, but having the meaning of "targets >> the stable ABI as first defined in CPython X.Y"), rather than feature >> release specific "cpXYm" ones, then a *lot* of the extension module >> maintenance pain otherwise arising from more frequent CPython releases >> should be avoided. >> >> There'd still be a lot of other details to work out to turn the proposed >> release cadence change into a practical reality, but this is the key piece >> that I think is a primarily technical hurdle: simplifying the current >> "wheel-per-python-version-per-target-platform" community project build >> matrices to instead be "wheel-per-target-platform”. > > This requires getting people to mostly stop using the non-stable ABI, and > that could be a lot of work for projects that have existing C extensions that > don’t use the stable ABI or cython/cffi/… > > That said, the CPython API tends to be fairly stable over releases and even > without using the stable ABI supporting faster CPython feature releases > shouldn’t be too onerous, especially for projects with some kind of > automation for creating release artefacts (such as a CI system). > > Right, there would still be a non-zero impact on projects that ship binary > artifacts. > > Having a viable stable ABI as a target just allows third party projects to > make the trade-off between the upfront cost of migrating to the stable ABI > (but then only needing to rebuild binaries when their own code changes), and > the ongoing cost of maintaining an extra few sets of binary wheel archives. I > think asking folks to make that trade-off on a case by case basis is > reasonable, whereas back in the previous discussion I considered *only* > offering the second option to be unreasonable.
I agree. I haven’t seriously looked at the stable ABI yet, so I don’t know if there are reasons for now migrating to it beyond Py2 support and the effort required. For my own projects (both public and not) I have some that could possibly migratie to the stable ABI, and some that cannot because they access information that isn’t public in the stable ABI. I generally still use the non-stable C API when I write extensions, basically because I already know how to do so. Ronald
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
