Reference

[Steven D'Aprano]

On Tue, 04 Mar 2014 10:19:22 -0500, Jerry Hill wrote:

> On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>> If your intention is to treat None as a singleton sentinel, not as a
>> value, then you ought to use "is" to signal that intention, rather than
>> using == even if you know that there won't be any false positives.
> 
> In all of the years I've been on this list, I don't think I've seen more
> than one or two cases of someone deliberately treating None as a
> singleton sentinel.  In most cases, they're either checking the return
> value from a function 

Okay, that's not *precisely* a sentinel, but it's related. I don't know 
what to call that, but it's a sentinel applied to the return result 
rather than to an input parameter.


> or using it as a default argument to a function to
> force some default behavior when no parameter is passed.

I call that a sentinel. It doesn't match the Wikipedia definition of a 
sentinel, but I think that's wrong. What Wikipedia calls a sentinel, I 
would call a guard.

http://en.wikipedia.org/wiki/Sentinel_value



> I'm pretty
> sure you're going to say that the latter use is exactly where you should
> us 'is' instead of '=='.  

Yes.


> Respectfully, I disagree.
> 
> For a beginning python user, identity checking is an attractive
> nuisance. 

True. In Hypertalk, which was designed for non-coders, the "is" operator 
was a synonym for "==". Even after nearly 20 years of using Python, I 
still sometimes instinctively write "x is y" when I mean equality, 
especially the "if __name__ is __main__" idiom.


> The only time most beginners should use it is when comparing
> to None.

We're agreed on that.


> But, as soon as they are taught that there are two comparison
> operators, I start to see 'is' cropping up in more and more places where
> they ought to use '=='.  And the problem is that sometimes it works for
> them, and sometimes it doesn't.  Sure, students eventually need to
> understand the difference between identity and equality.  My problem is
> that by enshrining in python custom that the only correct way to compare
> to None is with 'is', we have to explain that concept way early in the
> teaching process.  I can't count the number of times that a thread has
> completely derailed into identity vs equality, then into interning of
> strings and small integers, and suddenly the thread is 40 messages long,
> and no one has actually talked about the code that was originally posted
> beyond that issue. 

Heh heh, welcome to the Internet.


> In approximately zero cases, have I seen code where
> 'is' versus '==' actually made any difference, except where the 'is' is
> wrong.  I've also never seen the supposedly ever-present boogie man of
> an object that mistakenly compares equal to None, much less seen that
> object passed to functions with None-based sentinels.
> 
> I feel like 'is' is an operator that ought to be saved for an advanced
> course.
> 
> Out of curiosity, do you think we should be doing truth checking with
> 'is'?  True and False are singletons, and it seems to me that the
> justification for idenity versus equality should be just as strong
> there, but I don't think I've ever seen anyone even suggest that.

Normally you shouldn't compare to True or False at all. Python duck-types 
truth-values, or to put it another way, you should normally only care 
about truthy and falsey values:

# Duck-typing is your friend
if flag: ...

# These are buggy unless you know flag is an actual bool
if flag == True: ...
if flag is True: ...

# Why convert to a canonical bool flag just to do a comparison?
if bool(flag): ...

# Not this
if bool(flag) is True:

# I never know when to stop
if bool(flag) is True is True is True is True is True is True: ...




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/