David Mertz writes:

 > [T]he semantics of __main__ being implicitly defined when scripts
 > are run is easy to explain.

Especially to C programmers on Unix. ;-)

To be honest, I think this is pretty icky[1].  IMO, it would be more
consistent with the Python runtime if it were a function is_main() and
lived in sys.

The existing idiom is a sort of easter egg, but it is (almost[2])
implied by the structure and semantics of modules, and almost as easy
to explain as "if __main__" would be.  __main__ *appears* to be easy
to explain because the syntax is so simple, but it's not obvious (to
me, anyway) what it should be inside of eval().  And is it an
attribute of the script itself (which new users don't necessarily
think of as an object in Python), or of builtins, which is where most
builtin identifiers live?  Pretty clearly it's part of the module
namespace, but to many new users that's going to require an explanation
almost as deep as "if __name__ == '__main__'" does.

 > I don't think this would break anything.

Just my heart! ;-)


Footnotes: 
[1]  I've been lifetime banned from use of the adjective "un-Pythonic". :-)

[2]  You need the small additional assumption that __name__ is
initialized to a specific value when running outside of the import system.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5CXEHTZZSDNA5GWCRHTMRV5FHHPX6U2C/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to