[Python-Dev] LSB: Binary compatibility
"Martin v. Löwis"
martin at v.loewis.de
Mon Dec 4 20:05:13 CET 2006
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.
My first reaction is that this is difficult due to the usage of
function-like macros. However, if we replaced those with C functions
(perhaps has a compile-time choice), and if we would also hide
the layout of structures, I think providing binary compatibility
(with a certain baseline version, or multiple of these) would
Of course, several things need to be considered, e.g.
- making Py_INCREF/Py_DECREF functions is likely a bad idea
for performance reasons. OTOH, it seems safe that
Py_INCREF/Py_DECREF can remain as-is for the rest of 2.x.
- hiding PyTypeObject is a bad idea for source compatibility.
OTOH, we already try to make only compatible changes to
it (except when we don't :-), so exposing this as stable
ABI might actually work.
- certain kinds of modules likely need to be ruled out, e.g.
modules that extend the layout of existing types (it would
fail to compile because the base struct becomes an
All in all, I think providing binary compatibility would
be feasible, and should be attempted. What do you think?
More information about the Python-Dev