On Mon, Jun 8, 2020 at 6:49 AM Jack Jansen <jack.jansen@cwi.nl> wrote: [ munch good points ]
That means that a simple measure, such as supplying a header file that provides backward compatibility back to 3.6 and telling extension module distributors to copy this file into their distribution may be just as good as a more complex solution. And if you want to get fancy you could add a script “genpycompatheader” which creates that include file in future Python distributions.
Something I myself have been guilty of is not specifying *who* backward compatibility is for, because I think there are (at least) two different kinds of developer / user.
To me, backwards compatibility means "I can upgrade to a new version and all my stuff still works". In the case of Python, that should, as far as possible, mean extension modules continue to compile without any changes at all. Nothing to install, no code changes or patches, everything Just Works.
And yes I realise Python has never guaranteed binary compatibility for extension modules from version to version, and sometimes source compatibility has not been guaranteed either. That's why I wrote "as far as possible". And eventually the old C API *will* be broken, and those extension modules that haven't been updated will stop compiling.
My suggestion about freezing Python.h is aimed at this kind of backwards compatibility, not breaking existing stuff for as long as possible.
The other kind of backwards compatibility, as Victor has well explained, is module writers who are updating their code to the new API, but need to still work with the older versions of Python. Even though these developers are by definition willing to make changes, I would still prefer to have everything they need, new headers and functions and whatever else, included in the standard Python source, for both old and new versions.
And my suggestion that the new API be in a renamed header file is to distinguish the first case from the second. It would allow a simple form of dependency analysis: "Has this code been updated to the new API?" becomes "grep Python.h"
--
cheers,
Hugh Fisher