Prev: python on a thumb drive?
Next: Escaping variable names
From: Jack Diederich on 5 Mar 2010 15:58
On Fri, Mar 5, 2010 at 2:54 PM, Steven D'Aprano
<steve(a)remove-this-cybersource.com.au> wrote:
> On Fri, 05 Mar 2010 15:01:23 -0400, Rolando Espinoza La Fuente wrote:
>
>> On Fri, Mar 5, 2010 at 2:32 PM, mk <mrkafk(a)gmail.com> wrote:
>>> Arnaud Delobelle wrote:
>>>
>>>>>>> 1 == True
>>>>
>>>> True
>>>>>>>
>>>>>>> 0 == False
>>>>
>>>> True
>>>>
>>>> So what's your question?
>>>
>>> Well nothing I'm just kind of bewildered: I'd expect smth like that in
>>> Perl, but not in Python.. Although I can understand the rationale after
>>> skimming PEP 285, I still don't like it very much.
>>>
>>>
>> 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.

-Jack
From: Terry Reedy on 5 Mar 2010 16:27
On 3/5/2010 1:30 PM, MRAB wrote:
> mk wrote:
>> >>> isinstance(False, int)
>> True
>> >>>
>> >>> isinstance(True, int)
>> True
>>
>> Huh?
>>
>> >>>
>> >>> issubclass(bool, int)
>> True
>>
>> Huh?!
>>
> Python didn't have Booleans originally, 0 and 1 were used instead. When
> bool was introduced it was made a subclass of int so that existing code
> wouldn't break.

And because it is useful to make it so.

Terry Jan Reedy


From: Robert Kern on 5 Mar 2010 17:09
On 2010-03-05 14:58 PM, Jack Diederich wrote:
> On Fri, Mar 5, 2010 at 2:54 PM, Steven D'Aprano
> <steve(a)remove-this-cybersource.com.au> wrote:
>> On Fri, 05 Mar 2010 15:01:23 -0400, Rolando Espinoza La Fuente wrote:
>>
>>> On Fri, Mar 5, 2010 at 2:32 PM, mk<mrkafk(a)gmail.com> wrote:
>>>> Arnaud Delobelle wrote:
>>>>
>>>>>>>> 1 == True
>>>>>
>>>>> True
>>>>>>>>
>>>>>>>> 0 == False
>>>>>
>>>>> True
>>>>>
>>>>> So what's your question?
>>>>
>>>> Well nothing I'm just kind of bewildered: I'd expect smth like that in
>>>> Perl, but not in Python.. Although I can understand the rationale after
>>>> skimming PEP 285, I still don't like it very much.
>>>>
>>>>
>>> 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.

It depends on what you're doing. mk seems to want to distinguish booleans from
other objects from some reason.

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

From: Steven D'Aprano on 5 Mar 2010 18:09
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



--
Steven
From: Jack Diederich on 5 Mar 2010 18:48
On Fri, Mar 5, 2010 at 6:09 PM, Steven D'Aprano
<steve(a)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__. Both "1.0" and "Decimal(0, 1)" will return
False if the test is "is True" or "is False."

-Jack
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: python on a thumb drive?
Next: Escaping variable names