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

Discussion in 'Python' started by Gerald Britton, Jan 23, 2009.

  1. 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?
    Gerald Britton, Jan 23, 2009
    #1
    1. Advertising

  2. On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:

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



    --
    Steven
    Steven D'Aprano, Jan 23, 2009
    #2
    1. Advertising

  3. Gerald Britton

    Gary Herron Guest

    Steven D'Aprano wrote:
    > On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
    >
    >
    >> 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.
    >


    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.

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

    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

    >
    >
    Gary Herron, Jan 24, 2009
    #3
  4. Gerald Britton

    Robert Kern Guest

    Steven D'Aprano wrote:

    > 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
    Robert Kern, Jan 24, 2009
    #4
  5. On Fri, 23 Jan 2009 16:28:15 -0800, Gary Herron wrote:

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



    >>> class Empty:

    .... def __eq__(self, other):
    .... return not bool(other)
    ....
    >>> e = Empty()
    >>> e == None

    True
    >>> e is None

    False



    --
    Steven
    Steven D'Aprano, Jan 24, 2009
    #5
  6. Gerald Britton

    Steve Holden Guest

    Steven D'Aprano wrote:
    > On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
    >
    >> 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.
    >

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

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

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
    Steve Holden, Jan 24, 2009
    #6
  7. On Fri, 23 Jan 2009 20:33:45 -0500, Steve Holden wrote:

    > Steven D'Aprano wrote:
    >> On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
    >>
    >>> 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.
    >>

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

    >>> class Empty:

    .... def __eq__(self, other):
    .... return not bool(other)
    ....
    >>> e = Empty()
    >>> e == None

    True
    >>> e is None

    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.



    --
    Steven
    Steven D'Aprano, Jan 24, 2009
    #7
  8. Gerald Britton

    Steve Holden Guest

    Steven D'Aprano wrote:
    > On Fri, 23 Jan 2009 20:33:45 -0500, Steve Holden wrote:
    >
    >> Steven D'Aprano wrote:
    >>> On Fri, 23 Jan 2009 14:58:34 -0500, Gerald Britton wrote:
    >>>
    >>>> 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.
    >>>

    >> 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*
    >

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

    > Steve, in case you missed my earlier response:
    >
    >>>> class Empty:

    > ... def __eq__(self, other):
    > ... return not bool(other)
    > ...
    >>>> e = Empty()
    >>>> e == None

    > True
    >>>> e is None

    > 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
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
    Steve Holden, Jan 24, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Holden

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

    Steve Holden, Jan 23, 2009, in forum: Python
    Replies:
    9
    Views:
    322
    Steve Holden
    Jan 26, 2009
  2. length power
    Replies:
    2
    Views:
    69
    Rustom Mody
    Apr 10, 2014
  3. Skip Montanaro
    Replies:
    0
    Views:
    51
    Skip Montanaro
    Apr 10, 2014
  4. Johannes Schneider

    Re: why i have the output of [None, None, None]

    Johannes Schneider, Apr 10, 2014, in forum: Python
    Replies:
    0
    Views:
    46
    Johannes Schneider
    Apr 10, 2014
  5. Terry Reedy
    Replies:
    0
    Views:
    55
    Terry Reedy
    Apr 10, 2014
Loading...

Share This Page