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

[Jacob Holm]

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.

Jacob

-- 
Jacob Holm
CTO
Improva ApS