Upgrading Python Breaks Extensions; Fix proposal

[Bryan Olson]

I've done a Google search and found that others have had the same 
problem I'm having.  Any upgrade of Python, even from 2.0 to 2.1, breaks 
extension modules.  I'm working on MS-Windows, and the extension cannot 
find python20.dll, which is not surprising because it was replace with 
python21.dll.  I suppose I could put back the old DLL, but I don't know 
what that would do, since the rest of the system is using the newer DLL.

I don't the workings of Windows DLL's are to blame; Unix shared 
libraries would have the same problem.

If the interface to Python extensions actually changed, then certainly 
there's no avoiding updating the extensions.  The current system is much 
worse; any upgrade to Python breaks extensions, in many cases 
needlessly.

I don't think that giving different versions of dynamic libraries the 
same name, such as "python.dll", is a good idea.  It would just cause 
other problems.


So here's my proposal for a solution: don't make the extension load the 
library.  When the interpreter loads the extension, it should give it a 
pointer through which it can find all the library objects. The pointer 
could just be the system-dependent library pointer/handle, but more 
elegant would be a table of functions, defined the same on all 
platforms.

I think the change could be made without forcing code changes to 
extensions (though of course they'd need one last re-compile).  We just 
have to change the statically-linked stubs library.  We need one 
function that always gets linked in, and that the interpreter will call 
with the function-table pointer.  The utility functions that the library 
offers would be stubs that get the function pointers from the table, and 
call through them.

Of course we should think this through and try to find a way to 
negotiate versions, so that extensions last as long as possible.


Is this idea PEP-worthy?

--Bryan