Upgrading Python Breaks Extensions; Fix proposal

[Robin Becker]

In article <cpy9o2nrp1.fsf at cj20424-a.reston1.va.home.com>, Guido van
Rossum <guido at python.org> writes
>Robin Becker <robin at jessikat.fsnet.co.uk> writes:
>
>> In Tcl land, these problems caused the powers that be to implement their
>> own indirection scheme. Effectively the extension is passed a pointer to
>> a list of pointers. The extension indirects through them to get at the
>> real api. They have various rules to make things work reasonably when
>> pointers get added/subtracted to the real API. Seems to work quite well,
>> but there's a fixed time and space penalty.
>
>Hm, this looks a lot like the scheme that Windows already implements
>for linking to DLLs, as long as you use the same DLL name.  So what
>would the point be?
>
>The problem with either scheme is that we can't *know* that a new DLL
>won't break an existing extension -- each version introduces *some*
>incompatible change.  Most extensions don't use the affected APIs, so
>would be safe, but there's no way to know.  We could name the DLL
>python2.dll, and hope for the best, but some extensions might dump
>core.  We should then try to minimize this risk by never changing an
>API -- but that's very hard.
>
.....
That's exactly the problem that Tcl now has, extensions do get out of
date and crash for unknown reasons. At present we maintain 3 sets of
win32 dlls.  At some point after 2.2 it will be time to drop 1.5.2, 2.0
& 2.1. It would be better if the dlls could be tagged with the API
number as that changes less frequently or am I mistaken.
-- 
Robin Becker