[Python-Dev] LSB: Binary compatibility

["Martin v. Löwis"]

Neal Norwitz schrieb:
>> All in all, I think providing binary compatibility would
>> be feasible, and should be attempted. What do you think?
> 
> Let's assume that 2.4 is the first LSB version.  The ABI is different
> for 2.4 and 2.5.  We can't change the ABI for 2.5 since it's already
> released and our policy is to keep it constant.

I'm not absolutely sure it's true, because it may be possible to
integrate the 2.4 ABI into future 2.5 releases by means of symbol
versioning, but, more likely, that's not possible (as you likely
can't represent the difference in symbol versions).

> Where does that leave us for moving forward?  Would we have to modify
> 2.5 to make it entirely compatible with 2.4?  Can we skip 2.5
> altogether and worry about making 2.6 compatible with 2.4?

The most likely outcome is that LSB 3.2 won't provide any Python ABI,
but just a Python API (for a scripting language, that's enough to
achieve portability of applications). With that, extension modules
would not be portable across releases.

Then, with LSB 4.0, we could try to specify an ABI as well. Whether
that would be the 2.4 ABI, the 2.5 ABI, or the 2.6 ABI must be
decided.

> Even if
> so, that means no matter what we still need to make 2.4 compatible
> APIs going forward, right?  That will require some archeaology to
> determine preciesly what we changed from 2.4.

The LSB people are happy if we declare a subset of the ABI as stable.
So if PyFrame_New wasn't in the ABI, that would probably be just fine.

I think most ABI breakages are due to changes to structure layout,
and we should remove all reliance on structure layout out of the
ABI - requiring that ABI-compliant extensions use accessor functions
for everything.

> Is our current practice of the following change acceptable?
> 
> Original:
>  PyAPI_FUNC(xxx) Py_Foo(xxx);
> 
> New version:
>  PyAPI_FUNC(xxx) Py_FooEx(xxx, yyy);
>  #define Py_Foo(x) Py_FooEx(x, NULL)
> 
> And similarly in the C file, but keeping the original PyFoo with
> something like:
> 
>  xxx Py_FooEx(...) { ... }
>  #undef Py_Foo
>   xxx Py_Foo(xxx) { return Py_FooEx(xxx, NULL); }

This would be perfectly fine for ABI stability. They could even
accept if we just changed the signature of Py_Foo, and use
symbol versioning to provide the old definition (*) - but for API
evolution, that wouldn't work, of course.

It would mean that extension writers need the old header files
to build extensions. The LSB people would be fine with that -
they provide a complete set of header files to build LSB-compatible
binaries, anyway (so they can tell people: use these headers,
and your binaries will be ABI-compliant).

Regards,
Martin


(*) symbol versioning would help in cases where we change
a parameter to be of type Py_ssize_t now: we'd provide another
definition (with an old version number) that has the original
signature, and do the same forwarding.