(original) (raw)
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.
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@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@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)