[Python-Dev] What version is an extension module binary compatible with (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Mar 30 00:31:42 EDT 2017

On 29 March 2017 at 02:18, Paul Moore <p.f.moore at gmail.com> wrote:

On 28 March 2017 at 12:24, Miro Hrončok <mhroncok at 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 PySliceAdjustIndices 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)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list