[Python-Dev] Strange artifacts with PEP 3121 and monkey-patching sys.modules (in csv, ElementTree and others) (original) (raw)

Eli Bendersky eliben at gmail.com
Sun Aug 11 15:03:19 CEST 2013

On Sun, Aug 11, 2013 at 2:58 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Sat, 10 Aug 2013 18:06:02 -0700 Eli Bendersky <eliben at gmail.com> wrote: > This solution has problems. For example, in the case of ET it would > preclude testing what happens when pyexpat is disabled (remember we were > discussing this...). This is because there would be no real way to create > new instances of such modules (they would all cache themselves in the init > function - similarly to what ET now does in trunk, because otherwise some > of its global-dependent crazy tests fail). > > A more radical solution would be to really have multiple instances of > state per sub-interpreter. Well, they already exist -- it's > PyStateFindModule which is the problematic one because it only remembers > the last one.

I'm not sure I understand your diagnosis. modulesperindex (and PyStateFindModule) is per-interpreter so we already have a per-interpreter state here. Something else must be interferring. Yes, it's per interpreter, but only one per interpreter is remembered in state->modules_by_index. What I'm trying to say is that currently two different instances of PyModuleObject within the same interpterer share the state if they get to it through PyState_FindModule, because they share the same PyModuleDef, and stat->modules_by_index keeps only one module per PyModuleDef.

Note that module state is just a field attached to the module object ("void *mdstate" in PyModuleObject). It's really the extension modules which are per-interpreter, which is a good thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130811/f5ae2fb8/attachment.html>

More information about the Python-Dev mailing list