Phillip J. Eby wrote:
> While trying to get my -z replacement patch to work, I stumbled
> across a bug in the -m implementation (and in runpy). It seems that
> when you run the code of a -m module, it is *not* run in the __main__
> module namespace!
>
> So even though __name__=='__main__', globals() is not
> sys.modules['__main__'].__dict__. This seems wrong to me. Does
> anybody know why runpy doesn't actually run the code in the target module?
After implementing the runpy explicit relative import tests over the
last couple of days, it actually occurred to me earlier today that I
didn't have a test for this scenario. When I thought of the test, I was
also pretty sure it would fail - it appears I was right :)
> One consequence of this is that the -i option is much less useful
> when you use -m, because the script's globals have disappeared before
> you get to the interpreter prompt.
>
> At this point, I've successfully gotten a -z replacement patch,
> except that it inherits this apparent bug from -m, which for a while
> led me to believe my patch was broken (when in fact it works fine,
> apart from inheriting the -m behavior).
>
> Does anybody know if this behavior is intended, and if so, why? And
> what are the consequences of changing/fixing it?
I think it's a bug - when fiddling with the sys module
runpy.run_module() only uses the real module name, and not the requested
run_name. It should actually modify both so that the assertion
"globals() is sys.modules[__name__].__dict__" is correct when running
the module.
So, I propose that if runpy.run_module is told it has permission to
modify the sys module, and run_name is specified and exists in
sys.modules, then runpy will use that module to execute the code,
instead of creating a new temporary module.
If run_name isn't in sys.modules, then the temporary module used to
execute the code will be stored in both places.
This is a semantic change so we can't really backport it, but we can at
least fix it for 2.6.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
