rustompmody at gmail.com
Tue Mar 4 17:24:22 CET 2014
On Tuesday, March 4, 2014 8:49:22 PM UTC+5:30, Jerry Hill wrote:
> On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano 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 or using it as a default argument to a function
> to force some default behavior when no parameter is passed. 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
> nuisance. The only time most beginners should use it is when comparing
> to None. 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.
> 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.
Beautifully put -- thanks Jerry!
> I feel like 'is' is an operator that ought to be saved for an advanced course.
My choice: have an isNone function which should take care of 90%
of the cases of valid 'is' (if I got Chris' statistics right) and avoid
most of the metaphysical BS about identity
More information about the Python-list