<var> is None vs. <var> == None

[Gerald Britton]

Hi -- Some time ago I ran across a comment recommending using <var> is
None instead of <var> == None (also <var> is not None, etc.) My own
testing indicates that the former beats the latter by about 30% on
average. Not a log for a single instruction but it can add up in
large projects.

I'm looking for a (semi)-official statement on this, but couldn't find
one with normal googling. Can someone please send a link?

 

[Steven D'Aprano]

Hi -- Some time ago I ran across a comment recommending using <var> is
None instead of <var> == None (also <var> is not None, etc.)

That entirely depends on whether you wish to test for something which
*is* None or something with *equals* None. Those two things have
different meanings.

I wonder, do newbies actually get the impression from somewhere that "is"
is a synonym for "=="?

My own
testing indicates that the former beats the latter by about 30% on
average. Not a log for a single instruction but it can add up in large
projects.

If you have a "large" project where the time taken to do comparisons to
None is a significant portion of the total time, I'd be very surprised.

var is None is a micro-optimization, but that's not why we do it. We do
it because usually the correct test is whether var *is* None and not
merely equal to None. Any random object might happen to equal None
(admittedly most objects don't), but only None is None.

 

[Gary Herron]

That entirely depends on whether you wish to test for something which
*is* None or something with *equals* None. Those two things have
different meanings.

Actually, for None, those two things *are* the same. If something
*equals* None, it also *is* None. This is a consequence of the fact
that there is only ever one value of None anywhere in the system.

I wonder, do newbies actually get the impression from somewhere that "is"
is a synonym for "=="?

Yes. Such questions pop up regularly, and are usually dealt with quickly.

If you have a "large" project where the time taken to do comparisons to
None is a significant portion of the total time, I'd be very surprised.

var is None is a micro-optimization, but that's not why we do it. We do
it because usually the correct test is whether var *is* None and not
merely equal to None. Any random object might happen to equal None
(admittedly most objects don't), but only None is None.

You don't have that quite right. The only way something can *equal*
None is if it *is* None.
None is not a value an object can have, but rather it is a (singleton)
object that can be referenced. Setting something *equal* to None is
accomplished by making it refer to the single None object, at which
point it *is* None.

Gary Herron

 

[Robert Kern]

var is None is a micro-optimization, but that's not why we do it. We do
it because usually the correct test is whether var *is* None and not
merely equal to None. Any random object might happen to equal None
(admittedly most objects don't), but only None is None.

Additionally, some objects that use rich comparisons to return other objects and not
booleans will simply fail when compared with None. The situations where you are testing
for None are frequently situations where you don't really know the kind of object you
might be getting, either.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Steven D'Aprano]

If something
*equals* None, it also *is* None. This is a consequence of the fact
that there is only ever one value of None anywhere in the system. ....
The only way something can *equal* None is if it *is* None.

.... def __eq__(self, other):
.... return not bool(other)
....False

 

[Steve Holden]

That entirely depends on whether you wish to test for something which
*is* None or something with *equals* None. Those two things have
different meanings.

No they don't, because the language *guarantees* the None object is a
singleton, so anything that *equals* None *is* None.

I wonder, do newbies actually get the impression from somewhere that "is"
is a synonym for "=="?

Who knows. But if they do they can easily be reeducated.

If you have a "large" project where the time taken to do comparisons to
None is a significant portion of the total time, I'd be very surprised.

var is None is a micro-optimization, but that's not why we do it. We do
it because usually the correct test is whether var *is* None and not
merely equal to None. Any random object might happen to equal None
(admittedly most objects don't), but only None is None.

Of course there can be pathological objects with bizarre comparison
methods. And the "is" test helps avoid them.

regards
Steve

 

[Steven D'Aprano]

No they don't, because the language *guarantees* the None object is a
singleton, so anything that *equals* None *is* None.

Twice in one day. Have they put funny chemicals in the water over there?
*wink*

Steve, in case you missed my earlier response:
.... def __eq__(self, other):
.... return not bool(other)
....False


An instance that compares equal to anything false doesn't strike me as
particularly bizarre or pathological. For instance, the Python Cookbook
has an implementation for the Null object pattern. The implementation
given compares unequal to everything, but suggests defining an
appropriate __eq__ if you need different behaviour.

 

[Steve Holden]

Twice in one day. Have they put funny chemicals in the water over there?
*wink*

Nope, but you know what newsgroup response propagation is like ...

Steve, in case you missed my earlier response:

... def __eq__(self, other):
... return not bool(other)
...
False


An instance that compares equal to anything false doesn't strike me as
particularly bizarre or pathological. For instance, the Python Cookbook
has an implementation for the Null object pattern. The implementation
given compares unequal to everything, but suggests defining an
appropriate __eq__ if you need different behaviour.

Sure, my syllogism was not strictly true, hence my final quote:

Of course there can be pathological objects with bizarre comparison
methods. And the "is" test helps avoid them.

Personally I believe that the Empty class is at least slightly pathological.

regards
Steve