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

[Alex Martelli]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.991184190.15727.python-list at python.org...
    ...
> That one lost me:  these embedded systems can't upgrade to a newer
release,
> but *can* upgrade to a new version of 1.5.2?  Fine, if they have some
secret
> hardware dependence on version number, we'll release 2.2 under the *name*
> 1.5.3 <wink>.

I dunno embedded systems from a hole in the ground, but note that the
"secret
dependence" is anything but unlikely on a Windows platform.  Programs that
embed Python, and Python extensions, there depend on "python15.dll" and
need to be recompiled and relinked even if nothing but the DLL's name has
changed.  As has been wistfully noted other times, it WOULD be nice to
remove
that DLL-name dependency: particularly with the current rate of twice-yearly
releases, Python users on Windows who don't recompile the extensions they
use, but rather depend on others releasing pre-built binaries, have a hard
time
keeping up-to-date.  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.
That
wouldn't work as is with ISO C prototypes, so a further cast would no doubt
be
needed to make what pythmen returns into the right type of pointer to
function, but that's a SMOP:-)

As presented, this would be substantial overhead, but it may be possible to
pare it down by making pythmen into a function to be called once only to
prepare (or at least expose) an array of function pointers -- if this only
needs
to target Windows (i.e., Unix, Mac &c are already free of this dependence on
DLL name -- I'm not sure, are they?), the data might be directly exposed by
the DLL, so the macros would do (*(pythmen[23]))(a,b,c), again with the
appropriate casting -- the current Tcl solution to this should be studied in
detail (the Tcl language has its issues, but some of the tools &c are well
worth imitation, IMHO -- Tk's not the ONLY usable thing about it:-).

What do you think -- worth a PEP?  If it's not to be a Windows-only thingie,
I'd need consulting from experts of other platforms to prepare said PEP...


Alex