[Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python

Guido van Rossum guido@beopen.com
Sun, 09 Jul 2000 20:49:26 -0500


> Guido van Rossum wrote:
> > 
> > ...
> > Nice idea...  Unfortunately it means that every module must be
> > changed.  If we want to do this, we'd best introduce a macro!
> > E.g. (untested):
> > 
> >   #define Py_INIT(modname) DL_EXPORT(void) init20##modname()

Paul Prescod replies:

> Why is it that the init function names has to change for each module?
> Why not PyModuleMain or something?

Because Python supports a configuration time option to link modules
statically.

BArry Scott replies:

> The key problem here is that the python engine needs to
> verify the version of python that the extension supports
> before allowing the extension to do anything dangerous.
> 
> Maybe the solution is a pair of functions and a bit of
> protocol.
> 
> The first function is used for version checking.
> 
> 	int check_version_##module_name();
> 
> The second function will do the init as today.
> 
> 	init init##module_name();
> 
> Based on the outcome of calling the check_version function
> python can decide if it should call the init function.
> 
> Issues with the check_version function that I can think of
> are:
> 
> * how is a python version represented?
> * should the check_version function be passed the calling
>   python's version? This would allow smart extensions to
>   adapt to the invoking python's version dependent features.

There are endless variations on this theme.  What's missing at the
moment is a bit of requirements analysis.  What's the problem we're
trying to solve here?  So far, the only problem that came up was that
on Windows, you get an obscure crash when trying to load an extension
built for Python 1.5(.x).  Do we really need a whole new version
negotiating architecture?  You can already get the version string by
looking at Py_GetVersion() -- this also answers the question of how a
version is represented.

On Windows, link-time compatibility is broken whenever we change the
second digit of the version number, e.g. 15, 16, 20.  On Unix, there's
also a different version (the API version, see modsupport.h) which is
checked when the module initializes itself (it's hidden in the call to
Py_InitModule() that the module makes).

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)