isinstance(False, int)

[Robert Kern]

On 2010-03-05 17:48 PM, Jack Diederich wrote:
> On Fri, Mar 5, 2010 at 6:09 PM, Steven D'Aprano
> <steve at remove-this-cybersource.com.au>  wrote:
>> On Fri, 05 Mar 2010 15:58:01 -0500, Jack Diederich wrote:
>>
>>>>> So, the pythonic way to check for True/False should be:
>>>>>
>>>>>>>> 1 is True
>>>>> False
>>>>
>>>> Why do you need to check for True/False?
>>>>
>>>>
>>> You should never check for "is" False/True but always check for
>>> equality.  The reason is that many types support the equality (__eq__)
>>> and boolen (__bool__ in 3x) protocols.  If you check equality these will
>>> be invoked, if you check identity ("is") they won't.
>>
>> Never say never.
>>
>> If you specifically want to test for True or False themselves, accepting
>> no substitutes, then using "is" is the obvious way, and using "==" is
>> clearly and obviously wrong because it does accept substitutes:
>>
>>>>> 1.0 == True
>> True
>>>>> decimal.Decimal(0, 1) == False
>> True
>
>
> Yes, obviously if you _really_ mean to test if something has the
> object identity of True or False then an "is" test is the way to go.
> I'm just not sure why you would ever do that.  Also, I'm not sure how
> your assertion matches up with the examples; The examples test for
> equality with a float that returns true for __eq__ and a Decimal that
> returns false for __eq__.

No, both comparisons return True. Decimal(0,1) is equal in value to 0 (and thus 
False). Comparing it to False using __eq__ returns True.

> Both "1.0" and "Decimal(0, 1)" will return
> False if the test is "is True" or "is False."

Yes. That is exactly what he is asserting.

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