Nick Coghlan added the comment: As Richard said, the __globals__ attributes of the functions are pointing at the real module dictionary, which may have been cleared when the temporary module was destroyed.
However, I just checked the docs and they don't actually mention the fact that run_path and run_module currently return a copy of the globals - they say they "return the resulting module globals dictionary." Since I would prefer it if the functions actually worked as advertised, I suggest we document the namespace copying as a CPython implementation detail, rather than as a guaranteed feature. That way we can eliminate these copy operations once the module namespace purging has been eliminated. Some related references: Don't purge module dicts before shutdown: issue 18214 Don't purge module dicts at all: issue 812369 More robust finalisation semantics: PEP 442 We should also tidy up the headings in the data model reference ( http://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy) so we can link directly to the section that mentions the CPython module clearing implementation detail this behaviour is designed to work around. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python stage: -> needs patch title: runpy.run_path gives functions with corrupted .__globals__ -> Document that runpy.run_path and run_module copy the module globals type: behavior -> enhancement versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18331> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
