Pragmatics of the is operator

[Steven D'Aprano]

On Sun, 27 Nov 2011 02:42:52 +0100, candide wrote:

>> Even if you can guarantee that your code base does not contain any
>> object which compares equal to None except for None itself (and how
>> would you do that? a full audit of every line of code in every library
>> you use?), the use of `is` should be preferred because it signals your
>> intention much better.
> 
> OK but tons of good code use "spam == None" ; for instance, many tests
> files in Python official code. A random example (from
> openshot/openshot/windows/MainGTK.py):

I don't know what openshot is, but I don't think it is "official" in the 
sense of being in the Python standard library:

>>> import openshot
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named openshot


But even if it were, the standard library is not written by superhuman 
perfect gods, only by ordinary human beings who can make mistakes. 
Comparing against None with == is not idiomatic Python, and is usually a 
mistake. It rarely leads to obvious bugs, so it can survive in code 
without notice for a long time.


>> If your intention is to accept arbitrary objects which compare equal to
>> None, than by all means use == for your comparison. But normally the
>> intention is to accept None, and nothing else.
> 
> 
> So, for the same reason, wouldn't it be better to use "if spam is True"
> against to "if spam == True"  (or better "if spam") ?

No. Normally should just say "if spam" and allow Python to test the 
truthiness of spam.

"if spam == True" is worse, because there are many truthy objects which 
are not equal to True, e.g. 42, "norwegian blue", [1, 2, 3] are all 
truthy objects that (almost always) should be accepted but will wrongly 
be rejected.

"if spam is True" is even worse, because there are many truthy objects 
that are not the True singleton. Old code, especially if it was written 
before the introduction of bools in (I think) 2.1 or 2.2, often uses 1 as 
the standard true-like value. To save typing, many people will still pass 
1 or 0 as an argument when a bool is expected, which will then fail if 
you test for identity.

The exception is if for some reason you actually care whether your flag 
is the True object and absolutely nothing else. This violates Python's 
preference for duck-typing and support for truthiness, but if you have a 
good reason, go right ahead.

Suppose spam is already a bool. Then "if spam" is enough, since spam is a 
bool. "if spam is True" is no more necessary than 

    if spam is True is True
    if spam is True is True is True
    if spam is True is True is True is True 
    if spam is True is True is True is True is True
    if spam is True is True is True is True is True is True
    # I never know when to stop...

The right place to stop is not to start. "if spam is True" is redundant.

And lastly, testing for identity against None is guaranteed by the 
language: any implementation of Python must have None a singleton. But 
True and False are not such a strong promise. A future version of Python, 
or another implementation, might not bother to make True and False 
singletons. (Doubletons?) Unlikely, but why make assumptions that you 
don't need to?



-- 
Steven