steve+comp.lang.python at pearwood.info
Tue Mar 4 16:42:03 CET 2014
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>
>> 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.
> I'm pretty
> sure you're going to say that the latter use is exactly where you should
> us 'is' instead of '=='.
> Respectfully, I disagree.
> For a beginning python user, identity checking is an attractive
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
> 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: ...
More information about the Python-list