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

Giovanni Bajo rasky at develer.com
Thu Jun 29 18:58:19 CEST 2006


Guido van Rossum wrote:

>> Real-world usage case for import __main__? Otherwise, I say screw it
>> :) [...] My personal argument is that if __name__ == '__main__' is
>> totally counter-intuitve and unpythonic. It also proves my memory:
>> after many years, I still have to think a couple of seconds before
>> rememebering whether I should use __file__, __name__ or __main__ and
>> where to put the damn quotes. The fact that you're comparing a
>> variable name and a string literal which seems very similar (both
>> with the double underscore syntax) is totally confusing at best.
>>
>> Also, try teaching it to a beginner and he will go "huh wtf". To
>> fully understand it, you must understand how import exactly works
>> (that is, the fact that importing a module equals evaluating all of
>> its statement one by one). A function called __main__ which is
>> magically invoked by the python itself is much much easier to grasp.
>> A different, clearer spelling for the if condition (like: "if not
>> __imported__") would help as well.
>
> You need to watch your attitude, and try to present better arguments
> than "I don't like it".

Sorry for the attitude. I though I brought arguments against if __name__:

- Harder to learn for beginners (requires deeper understanding of import
workings)
- Harder to remember (a string literal compared to a name with the same
naming convention)
- Often requires explicit sys.exit() which breaks python -i
- Broken by -mpkg.mod, and we ended up with another __magic_name__ just
because of this.
- (new) Defining a main() function is already the preferred style for
reusability, so __main__ would encourage the preferred style.

If you believe that these arguments collapse to "I don't like it", then no,
I don't have any arguments.
-- 
Giovanni Bajo



More information about the Python-Dev mailing list