[Python-ideas] PEP for executing a module in a package containing relative imports

Ron Adam rrr at ronadam.com
Sun Apr 22 00:50:29 CEST 2007

Jacob Holm wrote:
> Steven Bethard wrote:
>> On 4/21/07, Christian Heimes <lists at cheimes.de> wrote:
>>> If you like to introduce __main__ why not implement
>>> http://www.python.org/dev/peps/pep-0299 ? It proposes a __main__(*argv*)
>>> module level function that replaced the "if __name__ == '__main__'"
>>> idiom. The __main__ function follows the example of other programming
>>> languages like C, C# and Java.
>> I don't like the __main__ function signature. There are lots of
>> options, like optparse and argparse_ that are much better than
>> manually parsing sys.argv as the PEP 299 signature would suggest.
> I agree that optparse and argparse are better ways to parse a command 
> line than using sys.argv directly, but nothing in PEP299 would prevent 
> you from using them.
> In fact, I am pretty sure that with a suitable decorator on __main__ you 
> could make their use even simpler.
>>  And
>> if there's nothing to be passed to the function, why make it a
>> function at all? 
> Because you may want to call it from somewhere else, possibly with 
> different arguments?
>> Personally, I thought one of the pluses of the
>> current status quo (as well as what Brett is proposing here) is that
>> it *didn't* follow in the (misplaced IMHO) footsteps of languages like
>> C and Java. I think we're probably best letting dead PEPs lie.
> I find it very sad that PEP299 did in fact die, because I think it is 
> much cleaner solution than the proposal that started this thread. 
> That said, I would like to se a way to remove the __name__=='__main__' 
> weirdness.  I am +1 on resurrecting PEP299, but also +1 on adding a 
> "sys.main" that could be used in a new "if __name__=sys.main".  I am -1 
> on adding a builtin/global __main__ as proposed, because that would 
> clash with my own PEP299-like use of that name.

I had at one time (about 4 years ago) thought it was a bit strange.  But 
that was only for a very short while.

Python differs from other languages in a very important way.  python 
*always* starts at the top of the file and works it way down until if falls 
off the bottom.  What it does in between the top and the bottom is entirely 
up to you.  It's very dynamic.

Other languages *compile* all the code first without executing any of it. 
Then you are required to tell the the compiler where the program will 
start, which is why you need to define a main() function.

In Python, letting control fall off the bottom in order to start again at 
some place in the middle doesn't make much sense. It's already started, so 
you don't need to do that.


More information about the Python-ideas mailing list