On 2010-03-05 17:48 PM, Jack Diederich wrote:
On Fri, Mar 5, 2010 at 6:09 PM, Steven D'Aprano
<st...@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
--
http://mail.python.org/mailman/listinfo/python-list
