[Python-Dev] PEP 338 vs PEP 328 (original) (raw)

[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 PySysSetPath so that '' is NOT prepended to > > sys.path > > > when the -m switch is used > > > 2. Change runpy.runmodule to add a pkgname attribute if the module > > > being executed is inside a package > > > 3. Change import.c to check for pkgname if (and only if) > > name == > > > 'main' and use pkgname 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[0] 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 as yet...

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 mailing list