[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

isinstance(False, int

mk

3/5/2010 5:14:00 PM

>>> isinstance(False, int)
True
>>>
>>> isinstance(True, int)
True

Huh?

>>>
>>> issubclass(bool, int)
True

Huh?!

Regards,
mk
14 Answers

Arnaud Delobelle

3/5/2010 6:04:00 PM

0

mk <mrkafk@gmail.com> writes:

>>>> isinstance(False, int)
> True
>>>>
>>>> isinstance(True, int)
> True
>
> Huh?
>
>>>>
>>>> issubclass(bool, int)
> True
>
> Huh?!
>
> Regards,
> mk

Yes, and:

>>> True + False
1

In fact:

>>> 1 == True
True
>>> 0 == False
True

So what's your question?

--
Arnaud

Steven D'Aprano

3/5/2010 6:07:00 PM

0

On Fri, 05 Mar 2010 18:14:16 +0100, mk wrote:

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

mk

3/5/2010 6:33:00 PM

0

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.


Regards,
mk

Jean-Michel Pichavant

3/5/2010 6:54:00 PM

0

Steven D'Aprano wrote:
> On Fri, 05 Mar 2010 18:14:16 +0100, mk wrote:
>
>
>>>>> 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.
>
>
>
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.
Booleans are not ints, 0 does not *mean* False and veracity is not
quantification.


JM

Rolando Espinoza La Fuente

3/5/2010 7:01:00 PM

0

On Fri, Mar 5, 2010 at 2:32 PM, mk <mrkafk@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

>>> 0 is False
False

instead of ==, right?

Regards,

Rolando

Steven D'Aprano

3/5/2010 7:54:00 PM

0

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

3/5/2010 8:58:00 PM

0

On Fri, Mar 5, 2010 at 2:54 PM, Steven D'Aprano
<steve@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@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

3/5/2010 9:51:00 PM

0

On 3/5/2010 1:54 PM, Jean-Michel Pichavant wrote:
> 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

3/5/2010 10:09:00 PM

0

On 2010-03-05 14:58 PM, Jack Diederich wrote:
> On Fri, Mar 5, 2010 at 2:54 PM, Steven D'Aprano
> <steve@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@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

Steven D'Aprano

3/5/2010 11:10:00 PM

0

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