[Python-Dev] -z, -i and -m, maybe bug in runpy?

[Phillip J. Eby]

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
><zipfile_name>/__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].