[Python-Dev] libpython added to ABI tracker

[Nick Coghlan]

On 1 April 2014 21:23, Andrey Ponomarenko <aponomarenko at rosalab.ru> wrote:
>
> Nick Coghlan wrote:
>>
>> On 1 Apr 2014 01:38, "Victor Stinner" <victor.stinner at gmail.com> wrote:
>>>
>>> 2014-03-31 13:38 GMT+02:00 Andrey Ponomarenko <aponomarenko at rosalab.ru>:
>>>>
>>>> The public libpython API changes will be tracked here:
>>>> http://upstream-tracker.org/versions/python_public_api.html
>>>>
>>>> For now I've excluded only symbols starting with an underscore. What
>>
>> other
>>>>
>>>> symbols should be excluded?
>>>
>>> It's not a matter of underscore. You should define Py_LIMITED_API to
>>> 0x03020000 to test the stable ABI of Python 3.2.
>>>
>>> http://docs.python.org/dev/c-api/stable.html
>>
>> Well, we have more than one ABI, with different guarantees. The "no
>> leading
>> underscore" one we promise not to change in maintenance releases, but we
>> only preserve *API* compatibility in feature releases (mostly due to
>> structs changing size).
>>
>> The "stable ABI" (aka Py_LIMITED_API) is the one where we promise to hide
>> all the memory layout details and treat it as "additive only" so that
>> binaries built with previous releases keep working. That should never
>> break
>> ABI compatibility, and only get new additions if the macro definition is
>> bumped up to match the newer release.
>>
>> Cheers,
>> Nick.
>
>
> The stable libpython ABI with Py_LIMITED_API=0x03020000 will be tracked at
> http://upstream-tracker.org/versions/python_stable_api.html

Thanks! The "leading underscore means private" convention is also
applicable here (that's a general guideline for Python related APIs).

Interesting to see the UCS2 removal there for 3.3. That's a genuine
removal from the public ABI as part of PEP 393. I guess the reason
nobody complained is because most 3.2 Linux builds used the UCS4 ABI
instead, and the stable ABI hadn't seen broad adoption on Windows in
the 3.2->3.3 time frame.

Regarding the warnings for this one - is there a way for the checker
to warn if data structures are exposed directly, rather than as opaque
types? It's fine if there isn't, it would just be cool if there was -
one of the premises of the stable ABI is that it *doesn't* expose the
type definitions directly to consuming code, just the pointers to them
(hence allowing the struct size to change without actually breaking
compatibility with the defined ABI).

Regardless, this service already shows we've made some mistakes with
the stable ABI in previous releases - it is indicating there are new
symbols in the stable ABI for 3.3 and 3.4 that aren't properly guarded
with version constraints. That means it is currently possible to set
Py_LIMITED_API=0x03020000 and get something that won't actually run
properly on 3.2.

Georg, Larry, Benjamin - should checking these be added to PEP 101, so
we don't get the same thing happening for 3.5?

> I also added source-compatibility reports to the "public" API tracker:
> http://upstream-tracker.org/versions/python_public_api.html

Thanks again for setting these up!

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia