Message153540
| Author |
ncoghlan |
| Recipients |
brett.cannon, eli.bendersky, ezio.melotti, flox, ncoghlan |
| Date |
2012年02月17日.12:20:39 |
| SpamBayes Score |
0.0001032797 |
| Marked as misclassified |
No |
| Message-id |
<1329481241.11.0.995240423017.issue14035@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
In the case of *dependencies* that get refreshed, no they're *not* kept in sys.modules - they get overwritten by the originals when the sys.modules state gets restored.
The problem almost certainly arises because something, somewhere is doing "from x import y", where y is a function that depends on module globals in 'x'.
If 'x' ever drops out of sys.modules (e.g. because it is a fresh copy only there temporarily during an import), the x.__dict__ will have every attribute set to None and calls to 'y' will fail. (In Florent's original example, it was his "dummy/foo.py" that set of alarm bells and prompted me to look up the reference for the module GC problem).
That's why I'm opposed to touching import_fresh_modules to sweep this problem under the rug - as long as module globals finalisation isn't GC based, keeping a reference to a function in a module without ensuring you also hold a reference to the module itself is always going to be somewhat dubious. |
|