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