isinstance(False, int)
mk
True
>>>
>>> isinstance(True, int)
True
Huh?
>>>
>>> issubclass(bool, int)
True
Huh?!
Regards,
mk
Steve Holden
4
>>> 3+False
3
>>>
Just a brainfart from the BDFL - he decided (around 2.2.3, IIRC) that it
would be a good ideal for Booleans to be a subclass of integers.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/
Arnaud Delobelle
Yes, and:
>>> True + False
1
In fact:
>>> 1 == True
True
>>> 0 == False
True
So what's your question?
--
Arnaud
Steven D'Aprano
>>>> isinstance(False, int)
> True
> >>>
> >>> isinstance(True, int)
> True
>
> Huh?
Yes. Do you have an actual question?
> >>> issubclass(bool, int)
> True
>
> Huh?!
Exactly.
Bools are a late-comer to Python. For historical and implementation
reasons, they are a subclass of int, because it was normal for people to
use 0 and 1 as boolean flags, and so making False == 0 and True == 1 was
the least likely to break code.
E.g. back in the day, you would have something like:
{2:None}.has_key(2) -> 1
So folks would do:
print "The key is", ["missing", "present"][d.has_key(key)]
Which still works even now that has_key returns True or False rather than
1 or 0.
--
Steven
Rolando Espinoza La Fuente
[...]
>
> Just a brainfart from the BDFL - he decided (around 2.2.3, IIRC) that it
> would be a good ideal for Booleans to be a subclass of integers.
>
I would never figured out
>>> bool.__bases__
(<type 'int'>,)
Doesn't have side effects not knowing that False/True are ints?
Regards,
Rolando
MRAB
> >>> isinstance(False, int)
> True
> >>>
> >>> isinstance(True, int)
> True
>
> Huh?
>
> >>>
> 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.
mk
>>>> 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.
Regards,
mk
Jean-Michel Pichavant
reaction at first glance is legitimate.
Starting python from scratch, booleans would have not been a subclass of
int (just guessing though), 'cause it makes no sense from a design POV.
Booleans are not ints, 0 does not *mean* False and veracity is not
quantification.
JM
Rolando Espinoza La Fuente
> Arnaud Delobelle wrote:
>
>>>>> 1 == True
>>
>> True
>>>>>
>>>>> 0 == False
>>
>> True
>>
>> So what's your question?
>
> 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
>>> 0 is False
False
instead of ==, right?
Regards,
Rolando
mk
> Doesn't have side effects not knowing that False/True are ints?
It does, in fact I was wondering why my iterator didn't work until I
figured issubclass(bool, int) is true.
Regards,
mk
Steven D'Aprano
> On Fri, Mar 5, 2010 at 2:32 PM, mk <mrk...@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?
But if you need to, yes, that is one way. Another would be:
isinstance(flag, bool)
But generally, you can use any object as a flag without caring if it is
actually True or False.
--
Steven
Jack Diederich
<st...@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 <mrk...@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
Terry Reedy
> mk wrote:
>> >>> isinstance(False, int)
>> True
>> >>>
>> >>> isinstance(True, int)
>> True
>>
>> Huh?
>>
>> >>>
>> 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
Terry Reedy
> Steven D'Aprano wrote:
> Despite there are good reasons for bool to be int, the newcomer 'wtf'
> reaction at first glance is legitimate.
> Starting python from scratch, booleans would have not been a subclass of
> int (just guessing though), 'cause it makes no sense from a design POV.
You are just guessing. I would argue for what we have. An example of its
usefulness:
>>> scores =[True, False, True, True, False]
>>> score = sum(scores)
>>> score
3
Bools are also usefully used as sequence indexes.
Terry Jan Reedy
Robert Kern
> On Fri, Mar 5, 2010 at 2:54 PM, Steven D'Aprano
> <st...@remove-this-cybersource.com.au> wrote:
>>
>>> On Fri, Mar 5, 2010 at 2:32 PM, mk<mrk...@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?
>>
>
> 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
Steven D'Aprano
>>> 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
Jack Diederich
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
Chris Rebert
Arguably, these sorts of uses only require bool to be /convertible/ to
int, not to necessarily be a /subclass/ of int.
Cheers,
Chris
--
http://blog.rebertia.com
Robert Kern
> 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.
Bruno Desthuilliers
Nope. The pythonic way is to check for truth value - not for True or
False -, and to only use the identity test when wanting to test for
identity.