jackdied at gmail.com
Sat Mar 6 00:48:39 CET 2010
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
>>> 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
>>>> decimal.Decimal(0, 1) == False
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__. Both "1.0" and "Decimal(0, 1)" will return
False if the test is "is True" or "is False."
More information about the Python-list