[Python-Dev] PEP 328 and PEP 338, redux

Nick Coghlan ncoghlan at gmail.com
Thu Jun 29 13:15:20 CEST 2006


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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-Dev mailing list