At 08:29 PM 7/25/2007 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
At 12:16 AM 7/25/2007 +1000, Nick Coghlan wrote:
I've changed the behaviour in r56520 to simply leave the alterations to sys in place when the function terminates. While this is a definite change to the interface (and hence not a candidate for direct backporting), I think the difference is small enough for the 2.5 to 2.6 transition.
Your fix is a definite improvement for me, my "run any importable" patch is looking a lot better. There's just one problem left, which is that runpy is overwriting sys.argv[0] even if it doesn't need to. So, when running from a zipfile, sys.argv[0] ends up None, which is wrong.
However, if I ask runpy not to mess with sys, it creates a new module namespace to run the code in, bringing me right back to square one (i.e., not being run in __main__). Any thoughts?
My fallback at this point would be to add an option to run_module() to request that sys.argv[0] be used in place of calling _get_filename(). It seems ugly to do that, though, if only because there are already so many arguments to that function.
Adding a get_filename() method to ZipImporter objects would get you something better than None in sys.argv[0] (specifically, you would see
/__main__.py)
That's not the goal, actually; I want runpy to leave sys.argv[0] alone, so that we maintain the invariant that invoking sys.executable with sys.argv will re-run the same effective program. (And pointing to __main__.py inside the zipfile won't work!)
I'm actually becoming more and more in favour of reverting run_module back to its 2.5 semantics and adding a separate function that does the right thing for the -m switch.
+1; just make sure it has a way to request *not* overwriting sys.argv[0].