<div dir="ltr">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.<br><div><br>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.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 16, 2017 at 5:22 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hello,<br>
<br>
Nowadays we have an official mechanism for third-party C extensions to<br>
be binary-compatible accross feature releases of Python: the stable ABI.<br>
<br>
But, for non-stable ABI-using C extensions, there are also mechanisms<br>
in place to *try* and ensure binary compatibility.  One of them is the<br>
way in which we add tp_ slots to the PyTypeObject structure.<br>
<br>
Typically, when adding a tp_XXX slot, you also need to add a<br>
Py_TPFLAGS_HAVE_XXX type flag to signal those static type structures<br>
that have been compiled against a recent enough PyTypeObject<br>
definition.  This way, extensions compiled against Python N-1 are<br>
supposed to "still work": as they don't have Py_TPFLAGS_HAVE_XXX set,<br>
the core Python runtime won't try to access the (non-existing) tp_XXX<br>
member.<br>
<br>
However, beside internal code complication, it means you need to add a<br>
new Py_TPFLAGS_HAVE_XXX each time we add a slot.  Since we have only 32<br>
such bits available (many of them already taken), it is a very limited<br>
resource. Is it worth it? (*) Can an extension compiled against Python<br>
N-1 really claim to be compatible with Python N, despite other possible<br>
differences?<br>
<br>
(*) we can't extend the tp_flags field to 64 bits, precisely because of<br>
the binary compatibility problem...<br>
<br>
Regards<br>
<br>
Antoine.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>