At 07:06 AM 10/15/04 +1000, Nick Coghlan wrote: >Barry Warsaw wrote: >>On Thu, 2004-10-14 at 10:04, Bob Ippolito wrote: >> >>>>+1. Also, if a non-dotted module name can't be found, pyrun should be >>>>called to see if the module is actually a package (with an __main__ that >>>>lives in the package's __init__.py). > >Actually, if we were going to do something for packages, I'd be more >inclined to look for a script called __main__.py in the package directory, >rather than looking for a __main__ function inside __init__.py. Or else >simply run __init__.py itself as __main__ (i.e. allow the use of the >existing 'Python main' idiom inside a package's __init__.py) > >(Interestingly, that's at least the second time it has been suggested to >turn this idea into 'C-like main functions for Python'. '-m' is about >another way to invoke the current 'if __name__ == "__main__":' idiom. It >is most definitely *not* about creating a new idiom for main functions - >an activity which would seem to be PEP-worthy) Perhaps this means that -m is premature? I personally would rather wait for 2.5 if it means we get a nice, future-proof "main" convention out of the deal. While -m would not then be "backward compatible" with existing scripts, people could start changing scripts to match the convention as soon as there was an accepted PEP.
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