[Python-Dev] versioned .so files for Python 3.2

[Matthias Klose]

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<barry at python.org>:
>>>> On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>>>>
>>>>> 2010/6/24 Barry Warsaw<barry at 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