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

[Niki Spahiev]

30.5.2001, 09:34:16, Alex Martelli wrote:

[...]

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

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

IIRC some of Python modules export C API this way
(mxDateTime,ExtensionClass,wxPython) in order to use module import
instead of DLL dependency. But there are other ways.

If we make DLL called python15 that exports all python 1.5.2 functions but each
function is only:

void * PyMem_New(...)
{
        return python21.PyMem_New(...);
}

I think this DLL is enough to run most of extension modules. At least
if they run on unix. Maybe new PyMalloc will constrain this to
2.0 -> 2.1 only? But this solution does not need recompilation of
existing modules.

If we require recompilation, then i propose to add pointer to pythmen
function as argument to initmodule(). This way we can have statically
linked executables which import DLL modules as well. And since DLL
imports go trough jumptable anyway, overhead will be minimal.

Unfortunately i don't know how to tell MS LINK to use
python21.PyMem_New() etc. But i can binary patch for the same effect.

-- 
Best regards,
 Niki Spahiev