[Python-Dev] LSB: Binary compatibility

[Neal Norwitz]

On 12/4/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> At the LSB meeting, Jeff Licquia asked whether Python could provide
> binary compatibility with previous versions by use of ELF symbol
> versioning. In ELF symbol versioning, you can have multiple
> definitions for the same symbol; clients (e.g. extension modules)
> would refer to a specific version. During static linking, the most
> recent (?) version of the symbol is coded into the client object.
>
> With symbol versioning, you can change the implementation of a
> function and even its interface, and it will be compatible as
> long as you keep the original version around.

[in a separate message that Python 2.4 is the first targetted version]

> 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.

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?  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.

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); }

I'm not arguing against the LSB at all.  I think it's a good thing,
but I'm trying to understand what work needs to be done and how we can
acheive it in the face of apparent competing requirements.  I also
realize this is a one time cost and we don't need to address the
details right now.

n