On 30 March 2017 at 15:31, Nick Coghlan <ncogh...@gmail.com> wrote: > On 29 March 2017 at 02:18, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 28 March 2017 at 12:24, Miro HronĨok <mhron...@redhat.com> wrote: >>> I'd like some clarification on what ABI compatibility we can expect. >>> * Should the ABI be stable across patch releases (so calling >>> PySlice_AdjustIndices from an existing macro would be a bug)? >>> * Should the ABI be forward-compatible within a minor release (so modules >>> built for 3.6.0 should be usable with 3.6.1, but not vice versa)? >>> * Or should we expect the ABI to change even across patch releases? >> >> Given that binary wheels are built against a specific minor version >> (3.6, 3.5, ...) I would expect the ABI to be consistent over a minor >> release. That would fit with my expectations of the compatibility >> guarantees on patch releases. >> >> So I from what you describe, I'd consider this as a bug. Certainly, if >> someone built a C extension as a wheel using Python 3.6.1, it would be >> tagged as compatible with cp36, and pip would happily use it when >> installing to a Python 3.6.0 system, where it would fail. > > Right, this is the main problem - while "build against the X.Y.0 > headers" is useful advice, it's not something we've ever explicitly > stated, and it's not something we can reasonably expect all providers > of pre-built binary modules to do. > > Instead, it makes sense to explicitly strengthen the ABI guarantees > within CPython maintenance releases, and add some automated testing to > avoid accidental changes and oversights (similar to the pending test > to ensure magic number stability for cached bytecode files)
There's a website that has nice reports of ABI compatibility of various packages and might useful for testing. It shows up the added PySlice_AdjustIndices function in 3.6.1, along with PySlice_Unpack (and some changes to internal names, so probably not such a problem). https://abi-laboratory.pro/tracker/compat_report/python/3.6.0/3.6.1/496a4/abi_compat_report.html _______________________________________________ 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