[Python-Dev] PEP 328 and PEP 338, redux

Guido van Rossum guido at python.org
Tue Jun 27 18:40:21 CEST 2006


On 6/27/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote:
> >Bad idea IMO. The __name__ == "__main__" rule is so ingrained, you
> >don't want to mess with it.
>
> Actually, maybe we *do* want to, for this usage.
>
> Note that until Python 2.5, it was not possible to do "python -m
> nested.module", so this change merely prevents *existing* modules from
> being run this way -- when they could not have been before!
>
> So, such modules would require a minor change to run under -m.  Is this
> actually a problem, or is it a new feature?

It's a feature with a problem, that's what it is. :-)

My main concern is that people will feel the requirement to change all
existing main programs to use the endswith() idiom whether they need
it or not; there's a powerful meme that says you should be
future-compatible and who knows when your script will end up as part
of a package. So we'd see proliferation of the new idiom way beyond
necessity, which would be a shame.

I'd rather turn the argument around: if you had a "main" script that
used your package before 2.5, the script would be required to use
absolute import to access the package anyway. Presumably the script
would be copied to somewhere on $PATH and the package would be copied
somewhere on $PYTHONPATH (site-packages most likely) and the script
would invoke the package via its full name.

The new -m feature adds the possibility that exactly the same main
script may now also be copied (with the rest of the package) onto
$PYTHONPATH, without also copying it to $PATH, and it can be invoked
using -m.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list