[Python-Dev] Preventing 1.5 extensions crashing under 1.6/2.0 Python (original) (raw)

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

This is a multi-part message in MIME format.

------=_NextPart_000_020A_01BFFCD4.1683B5A0 Content-Type: text/plain; charset="iso-8859-1" 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 PyIsInitialized() in PyInitModule4()), 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.

    Barry

------=_NextPart_000_020A_01BFFCD4.1683B5A0 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; charset="iso-8859-1" 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 In-Reply-To: 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.

    Barry

Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev

------=_NextPart_000_020A_01BFFCD4.1683B5A0--