[Python-ideas] PEP for executing a module in a package containing relative imports
jh at improva.dk
Sat Apr 21 22:27:36 CEST 2007
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.
> 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
> 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.
More information about the Python-ideas