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 be possible. 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 incomplete type). All in all, I think providing binary compatibility would be feasible, and should be attempted. What do you think? Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
