[Python-Dev] multiple interpreters and extension modules (original) (raw)

Jeremy Kloth jeremy.kloth at 4suite.org
Sat Dec 23 04:09:56 CET 2006

On Friday 22 December 2006 7:16 pm, Guido van Rossum wrote:

I think you understand exactly what is happening. It is happening for good reasons. Rather than asking for a change in semantics, I recommend that you deal with it, either in your Python code, or in your extension. It's not likely to change.

I don't believe I was asking for a change in semantics, rather an additional, optional interface for extension module writers.

> 2) would it be worthwhile to have an extension loading function similar > to DllMain() for Windows' DLLs which is called multiple times with a flag > stating the reason for the call? For reference, see: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ >base/dllmain.asp I envision the reasons as: 'module init', 'module fini', > 'interpreter init', 'interpreter fini'. I see no current need for special > treatment of threads as they share the same interpreter space. > > As to question 2, I'm in the process of prototyping that approach to see > if it is feasible in our code and if so, (and people find it useful) I'll > attempt to write a PEP for that feature.

I'll add here that it has been brought up here before that extension module finalization is a feature that would be appreciated. With that, it is not that far to add support for initialization/finalization for each interpreter. That is, of course, using a DllMain-like solution.

> My current thoughts on that are instead of the current init > entry point in C modules, a new entry point is defined, and if found, > used in its place. That way, this proposal would be optional for > extension writers and existing modules would continue to work without > change.

With that approach in mind, I will be making changes so 4Suite will work in a production mod_python deployment (where the aforementioned error occurred). When that works, I'll come back with a proper PEP and patches against Python SVN to support its use. I hope no one was thinking I wanted someone else to do the work.

-- Jeremy Kloth http://4suite.org/

More information about the Python-Dev mailing list