[Python-ideas] Replacing the if __name__ == "__main__" idiom (was Re: making a module callable)

[Guido van Rossum]

On Mon, Nov 25, 2013 at 1:10 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

>
> On 26 Nov 2013 05:51, "Guido van Rossum" <guido at python.org> wrote:
> >
> > On Mon, Nov 25, 2013 at 11:42 AM, Barry Warsaw <barry at python.org> wrote:
> >>
> >> On Nov 26, 2013, at 01:12 AM, Steven D'Aprano wrote:
> >>
> >> >(1) Keep the status quo.
> >>
> >> I'd have no problem with this.  The current idiom doesn't seem broken
> to me,
> >> nor is it that hard to type.  I also don't think it's very hard to
> discover
> >> given how common it is.
> >
> >
> > All agreed, yet it is not that easy to type either (underscores and
> quotes require the shift key). Perhaps more important, it causes everyone
> who sees it first to wonder why the idiom isn't simpler.
> >
> >>
> >> >if __main__:
> >>
> >> If we *had* to make this easier to type, this would be my choice.  It
> doesn't
> >> even have to be read-only, given that __name__ can be messed with, but
> usually
> >> isn't.  Why then worry about __main__ getting messed with?
> >
> >
> > The problem with this is, how would you implement this? You can either
> make __main__ a builtin object with a magic __bool__() method, or you can
> plunk a bool named __main__ in every module namespace. I don't much like
> either.
>
> Shadowing would allow this to work without magic and with changes to only
> two modules: you could have a builtin __main__ that was always False and
> then set a __main__=True attribute in the main module.
>
> This still teaches the lesson about runtime introspection *and* could be
> used to teach an important lesson about name shadowing.
>
> Like Barry, this is my favourite of the suggestions so far, but I'm still
> not sure it's worth the hassle:
>
> - any such code would automatically be 3.5+ only (failing with NameError
> on earlier versions)
> - anything that emulates __main__ execution in a namespace other than the
> interpreter provided one would also need to be updated to set the new
> attribute
> - it adds "Why is __name__ wrong in __main__?" to the list of historical
> relics that can only be explained in terms of "the modern alternative
> didn't always exist"
>
> Potentially still a net win, though - call it +0 from me.
>
Still only -0 from me, mostly because of the first two of your items, and
because it just replaces one kind of magic with another.

But mostly I don't see why it has to involve a __dunder__ name (other
reminding the reader of the old idiom). The reason for using __dunder__
style for __name__ and '__main__' was clear: they impose on namespaces that
are nominally the user's (__name__ is a global variable, the value
'__main__' is a module name, we don't want to interfere with a user-defined
global variable named 'name' nor with a user-defined module named 'main').
But we don't need the same kind of caution for builtins (if the use defines
a variable is_builtin that variable wins).

(I don't get the point against my is_main() proposal that it also uses
magic. It's a builtin. *Of course* it is allowed to use magic.)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131125/ed3871b1/attachment.html>