<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 11, 2013 at 8:56 AM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 11 Aug 2013 08:49:56 -0700<br>
<div><div class="h5">Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:<br>
<br>
> On Sun, Aug 11, 2013 at 6:40 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> > On Sun, 11 Aug 2013 06:26:55 -0700<br>
> > Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:<br>
> > > On Sun, Aug 11, 2013 at 3:33 AM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>><br>
> > wrote:<br>
> > ><br>
> > > ><br>
> > > > Hi Eli,<br>
> > > ><br>
> > > > On Sat, 10 Aug 2013 17:12:53 -0700<br>
> > > > Eli Bendersky <<a href="mailto:eliben@gmail.com">eliben@gmail.com</a>> wrote:<br>
> > > > ><br>
> > > > > Note how doing some sys.modules acrobatics and re-importing suddenly<br>
> > > > > changes the internal state of a previously imported module. This<br>
> > happens<br>
> > > > > because:<br>
> > > > ><br>
> > > > > 1. The first import of 'csv' (which then imports `_csv) creates<br>
> > > > > module-specific state on the heap and associates it with the current<br>
> > > > > sub-interpreter. The list of dialects, amongst other things, is in<br>
> > that<br>
> > > > > state.<br>
> > > > > 2. The 'del's wipe 'csv' and '_csv' from the cache.<br>
> > > > > 3. The second import of 'csv' also creates/initializes a new '_csv'<br>
> > > > module<br>
> > > > > because it's not in sys.modules. This *replaces* the<br>
> > per-sub-interpreter<br>
> > > > > cached version of the module's state with the clean state of a new<br>
> > module<br>
> > > ><br>
> > > > I would say this is pretty much expected.<br>
> > ><br>
> > > I'm struggling to see how it's expected. The two imported csv modules are<br>
> > > different (i.e. different id() of members), and yet some state is shared<br>
> > > between them.<br>
> ><br>
> > There are two csv modules, but there are not two _csv modules.<br>
> > Extension modules are currently immortal until the end of the<br>
> > interpreter:<br>
> ><br>
> > >>> csv = __import__('csv')<br>
> > >>> wcsv = weakref.ref(csv)<br>
> > >>> w_csv = weakref.ref(sys.modules['_csv'])<br>
> > >>> del sys.modules['csv']<br>
> > >>> del sys.modules['_csv']<br>
> > >>> del csv<br>
> > >>> gc.collect()<br>
> > 50<br>
> > >>> wcsv()<br>
> > >>> w_csv()<br>
> > <module '_csv' from<br>
> > '/home/antoine/cpython/default/build/lib.linux-x86_64-3.4-pydebug/_<br>
> > <a href="http://csv.cpython-34dm.so" target="_blank">csv.cpython-34dm.so</a>'><br>
> ><br>
> ><br>
> > So, "sharing" a state is pretty much expected, since you are<br>
> > re-initializating an existing module.<br>
> > (but the module does get re-initialized, which is the point of PEP 3121)<br>
> ><br>
><br>
> Yes, you're right - this is an oversight on my behalf. Indeed, the<br>
> extensions dict in import.c keeps it alive once loaded, and only ever gets<br>
> cleaned up in Py_Finalize.<br>
<br>
</div></div>It's not the extensions dict in import.c, it's modules_by_index in the<br>
interpreter state.<br>
(otherwise it wouldn't be per-interpreter)<br>
<br>
The extensions dict holds the module *definition* (the struct<br>
PyModuleDef), not the module instance.<br></blockquote><div><br></div><div>Thanks for the clarification.<br><br>Eli <br></div></div><br></div></div>