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


On 26 Nov 2013 05:51, "Guido van Rossum" <guido@python.org> wrote:
>
> On Mon, Nov 25, 2013 at 11:42 AM, Barry Warsaw <barry@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)