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

Barry Scott barry@scottb.demon.co.uk
Wed, 2 Aug 2000 22:50:43 +0100

This is a multi-part message in MIME format.

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Mark Hammond [mailto:MarkH@activestate.com]
> Sent: 02 August 2000 00:14
> To: Barry Scott; python-dev@python.org
> Subject: RE: [Python-Dev] Preventing 1.5 extensions crashing under
> 1.6/2.0 Python
> > If someone in the core of Python thinks a patch implementing
> > what I've outlined is useful please let me know and I will
> > generate the patch.
> Umm - I'm afraid that I dont keep my python-dev emils for that long, and
> right now I'm too lazy/busy to dig around the archives.
> Exactly what did you outline?  I know it went around a few times, and I
> can't remember who said what.  For my money, I liked Fredrik's solution
> best (check Py_IsInitialized() in Py_InitModule4()), but as mentioned that
> only solves for the next version of Python; it doesnt solve the fact 1.5
> modules will crash under 1.6/2.0

	This is not a good way to solve the problem as it only works in a
	limited number of cases. 

	Attached is my proposal which works for all new and old python
	and all old and new extensions.

> It would definately be excellent to get _something_ in the CNRI 1.6
> release, so the BeOpen 2.0 release can see the results.

> But-I-doubt-anyone-will-release-extension-modules-for-1.6-anyway ly,

	Yes indeed once the story of 1.6 and 2.0 is out I expect folks
	will skip 1.6. For example, if your win32 stuff is not ported
	then Python 1.6 is not usable on Windows/NT.
> Mark.

Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

From: "Barry Scott" <barry@scottb.demon.co.uk>
Sender: <python-dev-admin@python.org>
To: <python-dev@python.org>
Subject: RE: [Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python
Date: Tue, 18 Jul 2000 23:36:15 +0100
Message-ID: <000701bff108$950ec9f0$060210ac@private>
MIME-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-UIDL: 5c981bb22b1a76163266dc06120e339a
X-BeenThere: python-dev@python.org
X-Mailman-Version: 2.0beta4

Mark's comment about what I'd come up with being too complex
inspired this simpler solution.

Change the init function name to a new name PythonExtensionInit_ say.
Pass in the API version for the extension writer to check. If the
version is bad for this extension returns without calling any python
functions. Add a return code that is true if compatible, false if not.
If compatible the extension can use python functions and report and
problems it wishes.

int PythonExtensionInit_XXX( int invoking_python_api_version )
	if( invoking_python_api_version != PYTHON_API_VERSION )
		/* python will report that the module is incompatible */
		return 0;

	/* setup module for XXX ... */

	/* say this extension is compatible with the invoking python */
	return 1;

All 1.5 extensions fail to load on later python 2.0 and later.
All 2.0 extensions fail to load on python 1.5.

All new extensions work only with python of the same API version.

Document that failure to setup a module could mean the extension is
incompatible with this version of python.

Small code change in python core. But need to tell extension writers
what the new interface is and update all extensions within the python
CVS tree.


Python-Dev mailing list