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
--
http://mail.python.org/mailman/listinfo/python-list
