[Python-Dev] PEP 328 and PEP 338, redux (original) (raw)

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,withoutalsocopyingittoPYTHONPATH, without also copying it to PYTHONPATH,withoutalsocopyingittoPATH, 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