Reference

[Steven D'Aprano]

Definition of insanity

Doing the same thing over and over again & expecting different results

*rolls dice*

 

[Alexander Blinne]

Am 03.03.2014 19:48, schrieb Terry Reedy:

The 'is' operator has three uses, two intended and one not. In
production code, 'is' tests that an object *is* a particular singular
object, such as None or a sentinel instance of class object.

Just a bit of statistics on this one from a recent small project:

<13:51:20> alex@firefly$ grep ' is ' *.py | wc
65 415 3234
<13:51:35> alex@firefly$ grep ' is None' *.py | wc
43 243 1948
<13:51:40> alex@firefly$ grep ' is not None' *.py | wc
21 167 1241
<13:51:44> alex@firefly$ grep ' is False' *.py | wc
1 5 45

No other uses if 'is' found in almost 3 KLOC...

 

[Chris Angelico]

Am 03.03.2014 19:48, schrieb Terry Reedy:

Just a bit of statistics on this one from a recent small project:

<13:51:20> alex@firefly$ grep ' is ' *.py | wc
65 415 3234
<13:51:35> alex@firefly$ grep ' is None' *.py | wc
43 243 1948
<13:51:40> alex@firefly$ grep ' is not None' *.py | wc
21 167 1241
<13:51:44> alex@firefly$ grep ' is False' *.py | wc
1 5 45

No other uses if 'is' found in almost 3 KLOC...

Lemme spin you up a different way of doing it, which actually looks
for the operators.

https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py

Run across the Python stdlib, that tells me there are 4040 uses of
is/is not, of which 16 compare against False, 18 against True (see?
Python has a bias for truth above falsehood!), and 3386 against None.
The other 620 are probably mostly sentinel objects, but I didn't look
at them.

ChrisA

 

[Jerry Hill]

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.

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.

 

[Chris Angelico]

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.

Normal truth testing is done like this:

if cond:

This isn't truth testing, this is checking the identity of what's in cond:

if cond is True:

And that's specifically testing for something much tighter than
truthiness. As you can see from my stats above, that's actually fairly
rare. Usually you'd just accept that True, 1, "yes", [1,2,3], and
1.2345 are all equally true.

ChrisA

 

[Steven D'Aprano]

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: ...

 

[Chris Angelico]

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

The banana problem.

ChrisA

 

[Roy Smith]

The banana problem.

ChrisA

You can refactor that as:

eval(" is ".join(itertools.chain(["if bool(flag)"], [str(t) for t in
itertools.repeat(True)])))

 

[Rustom Mody]

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.

+100

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

 

[MRAB]

The banana problem.

Speaking of which:

The 'right' way to peel a banana
http://www.telegraph.co.uk/news/good-to-share/10664935/The-right-way-to-peel-a-banana.html

 

[Alexander Blinne]

Am 04.03.2014 15:06, schrieb Chris Angelico:

https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py

I have always found it quite nice that the python parser is so easy to
use from within python itself.

Run across the Python stdlib, that tells me there are 4040 uses of
is/is not, of which 16 compare against False, 18 against True (see?
Python has a bias for truth above falsehood!), and 3386 against None.

I think i will have to rephrase my "is False" condition to make it more
truthy

 

[Chris Angelico]

Am 04.03.2014 15:06, schrieb Chris Angelico:

I have always found it quite nice that the python parser is so easy to
use from within python itself.

Yes. Until I put together the original version of that, to search for
PEP 463 translation candidates, I'd never used the ast module other
than for literal_eval. It's marvelously powerful.

I think i will have to rephrase my "is False" condition to make it more
truthy

if x is False:

-->

if not x:

ChrisA

 

[Antoon Pardon]

Op 04-03-14 16:25, Chris Angelico schreef:

Normal truth testing is done like this:

if cond:

In an other language with real booleans where an if only accepts a
boolean that would be true. In python this is testing for "something."

This isn't truth testing, this is checking the identity of what's in cond:

if cond is True:

And that's specifically testing for something much tighter than
truthiness. As you can see from my stats above, that's actually fairly
rare. Usually you'd just accept that True, 1, "yes", [1,2,3], and
1.2345 are all equally true.

No I usually don't accept that. A number different from 0 is not the same
as a none-empty list. I usally don't want to treat them the same.