[Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
Phillip J. Eby
pje at telecommunity.com
Sun Jun 18 23:37:30 CEST 2006
At 02:03 PM 6/18/2006 -0700, Guido van Rossum wrote:
>On 6/18/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote:
> > >On 6/18/06, Nick Coghlan <ncoghlan at iinet.net.au> wrote:
> > > > The 'bug fix' solution would be:
> > > >
> > > > 1. Change main.c and PySys_SetPath so that '' is NOT prepended to
> > > sys.path
> > > > when the -m switch is used
> > > > 2. Change runpy.run_module to add a __pkg_name__ attribute if
> the module
> > > > being executed is inside a package
> > > > 3. Change import.c to check for __pkg_name__ if (and only if)
> > > __name__ ==
> > > > '__main__' and use __pkg_name__ if it is found.
> > >
> > >That's pretty heavy-handed for a pretty esoteric use case. (Except #1,
> > >which I think should be done regardless as otherwise we'd get a
> > >messed-up sys.path.)
> > Since the -m module is being run as a script, shouldn't it put the module's
> > directory as the first entry on sys.path?
>Yes for a top-level module. No if it's executing a module inside a
>package; it's really evil to have a package directory on sys.path.
> > I don't think we should change
> > the fact that *some* directory is always inserted at the beginning of
> > sys.path -- and all the precedents at the moment say "script directory", if
> > you consider -c and the interactive interpreter to be scripts in the
> > current directory. :)
>You have a point about sys.path being special. It could be the
>current directory instead of the package directory.
Mightn't that be a security risk, in that it introduces an import hole for
secure scripts run with -m? Not that I know of any such scripts existing
If it's not the package directory, perhaps it could be a copy of whatever
sys.path entry the package was found under - that wouldn't do anything but
make "nearby" imports faster.
More information about the Python-Dev