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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4