On 24.06.2010 22:46, Barry Warsaw wrote:
On Jun 24, 2010, at 02:28 PM, Barry Warsaw wrote:
On Jun 24, 2010, at 01:00 PM, Benjamin Peterson wrote:
2010/6/24 Barry Warsaw<ba...@python.org>:
On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
2010/6/24 Barry Warsaw<ba...@python.org>:
Please let me know what you think. I'm happy to just commit this to the
py3k branch if there are no objections<wink>. I don't think a new PEP is
in order, but an update to PEP 3147 might make sense.
How will this interact with PEP 384 if that is implemented?
I'm trying to come up with something that will work immediately while PEP 384
is being adopted.
But how will modules specify that they support multiple ABIs then?
I didn't understand, so asked Benjamin for clarification in IRC.
<gutworth> barry: if python 3.3 will only load x.3.3.so, but x.3.2.so supports
the stable abi, will it load it? [14:25]
<barry> gutworth: thanks, now i get it :) [14:26]
<barry> gutworth: i think it should, but it wouldn't under my scheme. let me
think about it
So, we could say that PEP 384 compliant extension modules would get written
without a version specifier. IOW, we'd treat foo.so as using the ABI. It
would then be up to the Python runtime to throw ImportErrors if in fact we
were loading a legacy, non-PEP 384 compliant extension.
Is it realistic to never break the ABI? I would think of having the ABI encoded
in the file name as well, and only bump the ABI if it does change. With the
"versioned .so files" proposal an ABI bump is necessary with every python
version, with PEP 384 the ABI bump will be decoupled from the python version.
Matthias
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
