[Python-Dev] Usefulness of binary compatibility accross Python versions? (original) (raw)
Guido van Rossum guido at python.org
Sat Dec 16 12:34:02 EST 2017
- Previous message (by thread): [Python-Dev] Usefulness of binary compatibility accross Python versions?
- Next message (by thread): [Python-Dev] Usefulness of binary compatibility accross Python versions?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 tpXXX slot, you also need to add a PyTPFLAGSHAVEXXX 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 PyTPFLAGSHAVEXXX set, the core Python runtime won't try to access the (non-existing) tpXXX member. However, beside internal code complication, it means you need to add a new PyTPFLAGSHAVEXXX 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 tpflags 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>
- Previous message (by thread): [Python-Dev] Usefulness of binary compatibility accross Python versions?
- Next message (by thread): [Python-Dev] Usefulness of binary compatibility accross Python versions?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]