Comparison with False - something I don't understand

[Stephen Hansen]

On 12/2/10 2:02 AM, Harishankar wrote:
> On Thu, 02 Dec 2010 00:15:42 -0800, Alice Bevan–McGregor wrote:
>> The bool type is a subclass of int!  (Run those lines in a Python
>> interpreter to see.  ;)
>>
>>> if var == False:
>>
>> if var is False: …
> 
> So "var is False" is safer to use when I want to specifically check 
> whether var is set to False and not 0 or None?

Equality is a somewhat fuzzy concept.

By convention and habit, its usually fine and clear: but its still fuzzy
and up to each individual object involved to answer the question of
equality.

Now, its generally suggested in Python to do fairly vague truth testing:
"if x" and "if not x" as opposed to concepts like "if x == True" and "if
x == False" because the former is broad but usually more correct, and
the latter can lead to some unexpected semantics.

But that doesn't mean you must never check if something is False or
True: there are times when you really do want or need to see if _False_
is what's being returned, or _True_, or _None_. In this case, use "is",
yes, indeed.

The "is" operator checks absolute object identity, and so is how you
should do that check in cases where you want to test the distinction
between "Is it /False/, or just something false-ish or not-true or
nothing-ish?"

Generally speaking in Python, you usually want to do tests as "if x" or
"if not x".

But sometimes you need to know if "x" is a specific singleton value:
True, False or None. In that case, its okay to do "if x is True", "if x
is False" or "if x is None".

But you should only do that after the simple test is deemed
inappropriate in your API or situation.

And-- here's the rub-- while "is" is absolutely OK and right for you to
use to test if an object is one of those singletons, its *probably* NOT
what you want to do in any other situation*.

Outside of the True/False/None singletons, and places where you're doing
some special OOP-stuff, you almost certainly don't want to use 'is', but
use equality checking (even if its fuzzy, because its fuzzy) instead.

This demonstrates why "is" should be avoided except when in those
singleton situations (except when you need to, of course):

>>> a = 2
>>> b = 2
>>> a is b
True
>>> a == b
True
>>> a = 20000
>>> b = 20000
>>> a is b
False
>>> a == b
True

(If you're wondering why that's happening: Python makes very little in
the way of promises with regard to object identity. It may choose to
make a whole new int object of value 2 every time you type 2, or use the
same old int object each time: sure, presently it tends to only share
"small" integers for re-use, but that's not a promise, not a documented
feature, but a function of the current implementation. It could happen
tomorrow, in theory, that where a = 10000; b = 10000; become the same
object as far as "is" is concerned even though today they are
different... "is" should only be used in situations where you care about
absolute object identity, not *value*.)
--

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

* P.S. I'm not saying its never right to use "is" outside of The
Singletons. Just that its probably not, for most people, what they
actually should do in most code. There are numerous counter-examples, of
course. Its just a general guideline to follow. Until a need arises that
demonstrates otherwise.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20101202/506efd5c/attachment-0001.sig>