Giovanni Bajo wrote:
> Guido van Rossum wrote:
>
>>>> This is where I wonder why the "def __main__()" PEP was rejected in
>>>> the first place. It would have solved this problem as well.
>>> Could this be reconsidered for Py3k?
>> You have a point.
>
> AFAICT, there's nothing preventing it from being added in 2.6. It won't
> break existing code with the "if name == main" paradigm.
Writing modules that use the approach but want to work with both 2.5 and 2.6
becomes a little more annoying - such modules have to finish with the coda:
if __name__ == '__main__':
from sys import version_info, argv
if version_info < (2, 6):
sys.exit(__main__(argv))
The interpreter would also have to be careful to ensure that a __main__
variable in the globals isn't the result of a module doing "import __main__".
The above two reasons are what got PEP 299 killed the first time (the thread
is even linked from the PEP ;).
Another downside I've discovered recently is that calling sys.exit() prevents
the use of a post-mortem debugging session triggered by -i or PYTHONINSPECT.
sys.exit() crashes out of the entire process, so the post-mortem interactive
session never even gets started.
The only real upside I can see to PEP 299 is that "main is a function" is more
familiar to people coming from languages like C where you can't have run-time
code at the top level of a module. Python's a scripting language though, and
having run-time logic at the top level of a script is perfectly normal!
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
