isinstance(False, int)

[mk]

isinstance(False, int)
True

True

Huh?

True

Huh?!

Regards,
mk

 

[Arnaud Delobelle]

True

Huh?!

Regards,
mk

Yes, and:
1

In fact:
True

So what's your question?

 

[Steven D'Aprano]

True

Huh?

Yes. Do you have an actual question?

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.

 

[mk]

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]

True

Huh?

Yes. Do you have an actual question?

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]

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:

False

False

instead of ==, right?

Regards,

Rolando

 

[Steven D'Aprano]

So, the pythonic way to check for True/False should be:

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.

 

[Jack Diederich]

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]

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]

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]

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

 

[Jack Diederich]

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:

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

 

[Chris Rebert]

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.

Arguably, these sorts of uses only require bool to be /convertible/ to
int, not to necessarily be a /subclass/ of int.

Cheers,
Chris

 

[Robert Kern]

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

 

[Bruno Desthuilliers]

Rolando Espinoza La Fuente a écrit :

So, the pythonic way to check for True/False should be:

False

instead of ==, right?

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.