[Python-Dev] Usefulness of binary compatibility accross Python versions?

Guido van Rossum guido at python.org
Sat Dec 16 12:34:02 EST 2017


I think it's more acceptable to require matching versions now than it was
10 years ago -- people are much more likely to use installer tools like pip
and conda that can check version compatibility.

I think I'd be okay with dropping the flag-based mechanism you describe if
we were to introduce a clear mechanism that always rejected a dynamically
loaded module if it was compiled for a different Python version. This
should happen without any cooperation from the module. Perhaps in Python.h
we can introduce a reference to a variable whose name varies by version
(major.minor, I think) and which is defined only by the interpreter itself.
Or perhaps the version should be based on a separate ABI version.

On Sat, Dec 16, 2017 at 5:22 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

>
> Hello,
>
> Nowadays we have an official mechanism for third-party C extensions to
> be binary-compatible accross feature releases of Python: the stable ABI.
>
> But, for non-stable ABI-using C extensions, there are also mechanisms
> in place to *try* and ensure binary compatibility.  One of them is the
> way in which we add tp_ slots to the PyTypeObject structure.
>
> Typically, when adding a tp_XXX slot, you also need to add a
> Py_TPFLAGS_HAVE_XXX type flag to signal those static type structures
> that have been compiled against a recent enough PyTypeObject
> definition.  This way, extensions compiled against Python N-1 are
> supposed to "still work": as they don't have Py_TPFLAGS_HAVE_XXX set,
> the core Python runtime won't try to access the (non-existing) tp_XXX
> member.
>
> However, beside internal code complication, it means you need to add a
> new Py_TPFLAGS_HAVE_XXX each time we add a slot.  Since we have only 32
> such bits available (many of them already taken), it is a very limited
> resource. Is it worth it? (*) Can an extension compiled against Python
> N-1 really claim to be compatible with Python N, despite other possible
> differences?
>
> (*) we can't extend the tp_flags field to 64 bits, precisely because of
> the binary compatibility problem...
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171216/12fef982/attachment.html>


More information about the Python-Dev mailing list