version-number dependency in extensions (was Re: ConfigParser module in 1.52 is buggy?)

[Gordon McMillan]

[posted and mailed]

Tim Peters) wrote: 
>[Alex Martelli, about life on Windows]
>> ...

>> One conceptual scheme to enable that was suggested (a year ago, as I
>> recall) by imitation of what TCL does (on Windows, at least; I used
>> to be knowledgeable about Unix so's, too, but it has been years -- I'm
>> not current any more and may have forgotten key details).  A single
>> python. dll, (or maybe one per _major_ release to allow backwards
>> incompatibilities -- say python2. dll, python3.dll, &c) exposes a
>> single entry point, say 'pythmen' ("the fundament", in Greek:-).  All
>> functions currently exposed by the Python-C API become (in Python.h
>> &c, and on relevant platforms only) macros expanding to
>> (*(pythmen(23)))(a,b,c) i.e. , pythmen(n) returns the function
>> pointer for the n-th entry point.

>I must be missing the point.  If the DLL name doesn't change anymore,
>and subsequent releases are "compatible enough" that the collection of C
>API function names and signatures doesn't change either, what does this
>indirection buy (as opposed to letting the linker resolve the function
>names itself)?

Windows (when you link with an import lib) doesn't care about function 
names & signatures at runtime. Only that function1 is the 1st (physical) 
entry point in the dll (as opposed to the 1st logical entry point, in the 
stubs scheme above).

You can do it right now (in an exe loading Python) by using 
GetProcAddress(), but it's a pain. If a pyd could figure out what 
pythonxx.dll is in the process that loaded it, and had a map of Python 
versions to PYTHON_API_VERSIONs, I suppose it could do it, too.

- Gordon