bool behavior in Python 3000?

[Alan Isaac]

Is there any discussion of having real booleans
in Python 3000? Say something along the line
of the numpy implementation for arrays of type 'bool'?

Hoping the bool type will be fixed will be fixed,
Alan Isaac

 

[Michael Hoffman]

Is there any discussion of having real booleans
in Python 3000?

I'm not sure how the bools we have now are not "real."

> Say something along the line of the numpy implementation for arrays

of > type 'bool'?

What aspect of this do you want? A bool typecode for the stdlib array
module?

I can guess a number of things that you might mean, but it would be best
if you explained with an example of what current behavior is and what
you would like it to be.

 

[Peter Otten]

Is there any discussion of having real booleans
in Python 3000?

The last I have seen is

http://mail.python.org/pipermail/python-3000/2007-January/005284.html

Hoping the bool type will be fixed will be fixed,

Do you care to explain what is broken?

Peter

 

[Alan G Isaac]

> The last I have seen is
> http://mail.python.org/pipermail/python-3000/2007-January/005284.html

OK. Thanks.

> Do you care to explain what is broken?

I suppose one either finds coercion of arithmetic operations to int
to be odd/broken or does not. But that's all I meant.

My preference would be for the arithmetic operations *,+,-
to be given the standard interpretation for a two element
boolean algebra:
http://en.wikipedia.org/wiki/Two-element_Boolean_algebra

In contrast with the link above,
it does not bother me that arithmetic with ints and bools
produces ints.

Cheers,
Alan Isaac

 

[Steven Bethard]

I suppose one either finds coercion of arithmetic operations to int
to be odd/broken or does not. But that's all I meant.

My preference would be for the arithmetic operations *,+,-
to be given the standard interpretation for a two element
boolean algebra:
http://en.wikipedia.org/wiki/Two-element_Boolean_algebra

If I understand this right, the biggest difference from the current
implementation would be that::

True + True == True

instead of:

True + True == 2

What's the advantage of that? Could you give some use cases where that
would be more useful than the current behavior?

It's much easier to explain to newcomers that *, + and - work on True
and False as if they were 1 and 0 than it is to introduce them to a two
element boolean algebra. So making this kind of change needs a pretty
strong motivation from real-world code.

Steve

 

[Daniel]

Do you care to explain what is broken?

If I understand this right, the biggest difference from the current
implementation would be that::

True + True == True

instead of:

True + True == 2

What's the advantage of that? Could you give some use cases where that
would be more useful than the current behavior?

I prefer the use of 'and' and 'or', and they feel more pythonic than & and
+

 

[Bjoern Schliessmann]

Hoping the bool type will be fixed will be fixed,

Is there any type named "bool" in standard Python?

Regards,


Björn

--
BOFH excuse #207:

We are currently trying a new concept of using a live mouse.
Unfortunately, one has yet to survive being hooked up to the
computer.....please bear with us.

 

[Bjoern Schliessmann]

My preference would be for the arithmetic operations *,+,-
to be given the standard interpretation for a two element
boolean algebra:
http://en.wikipedia.org/wiki/Two-element_Boolean_algebra

[bool(True+True), bool(True+False)]

[True, True]

Works for me, or did I misunderstand you?

If you don't want explicitly to write bool, you could define your
own True and False classes.

Regards,


Björn

 

[Terry Reedy]

| Is there any discussion of having real booleans
| in Python 3000? Say something along the line
| of the numpy implementation for arrays of type 'bool'?

As far as I know, there is no such discussion among the developers.
Clp is always a different matter ;-)

 

[Ben Finney]

I'm not sure how the bools we have now are not "real."

I'm guessing that Alan is referring (at least in part) to this behaviour:

Python 2.4.4 (#2, Apr 5 2007, 20:11:18)
[...] True

Whereas a real bool type would have discrete values for True and False
that would not be equal to any other.

 

[Steven D'Aprano]

My preference would be for the arithmetic operations *,+,-
to be given the standard interpretation for a two element
boolean algebra:
http://en.wikipedia.org/wiki/Two-element_Boolean_algebra

[bool(True+True), bool(True+False)]

[True, True]

Works for me, or did I misunderstand you?

It seems to me that you deliberately misunderstood him. Why else would you
type-cast the integers 2 and 1 to bools to supposedly demonstrate that
there's nothing wrong with operations between bools returning ints?

I mean, by that logic, it should be okay if we had

False = []
True = [None]

because:

bool(False + True), bool(True + True)

also gives (True, True). But that doesn't justify the choice of bools
being lists any more than it justifies the choice of bools being ints.

 

[Steven D'Aprano]

It's much easier to explain to newcomers that *, + and - work on True
and False as if they were 1 and 0 than it is to introduce them to a two
element boolean algebra. So making this kind of change needs a pretty
strong motivation from real-world code.

Pretending that False and True are just "magic names" for 0 and 1 might be
"easier" than real boolean algebra, but that puts the cart before the
horse. Functionality comes first: Python has lists and dicts and sets
despite them not being ints, and somehow newcomers cope. I'm sure they
will cope with False and True not being integers either.

I mean, really, does anyone *expect* True+True to give 2, or that 2**True
even works, without having learnt that Python bools are ints? I doubt it.

And the old Python idiom for an if...then...else expression:

["something", "or other"][True]

tends to come as a great surprise to most newbies. So I would argue that
bools being ints is more surprising than the opposite would be.

 

[Paul Rubin]

Pretending that False and True are just "magic names" for 0 and 1 might be
"easier" than real boolean algebra, but that puts the cart before the
horse. Functionality comes first: Python has lists and dicts and sets
despite them not being ints, and somehow newcomers cope. I'm sure they
will cope with False and True not being integers either.

Are they are aren't they?

print 1 in [True]
print 1 == True
print len(set(map(type, [1, 1])))
print len(set(map(type, [1, True])))

 

[Steven Bethard]

It's much easier to explain to newcomers that *, + and - work on True
and False as if they were 1 and 0 than it is to introduce them to a two
element boolean algebra. So making this kind of change needs a pretty
strong motivation from real-world code.

Pretending that False and True are just "magic names" for 0 and 1 might be
"easier" than real boolean algebra, but that puts the cart before the
horse. Functionality comes first: Python has lists and dicts and sets
despite them not being ints, and somehow newcomers cope. I'm sure they
will cope with False and True not being integers either.

I mean, really, does anyone *expect* True+True to give 2, or that 2**True
even works, without having learnt that Python bools are ints? I doubt it.

And the old Python idiom for an if...then...else expression:

["something", "or other"][True]

tends to come as a great surprise to most newbies. So I would argue that
bools being ints is more surprising than the opposite would be.

I disagree. I think you'd get just as many odd stares if:

True + True == True

But I think all you're really saying is that newbies don't expect things
like +, -, *, etc. to work with bools at all. Which I agree is probably
true.

So it seems like you're really arguing for raising exceptions in all
these situations. That would actually be fine with me since I never use
bools as ints, but I suspect getting it past python-dev will be an
uphill battle since it will break large chunks of code.

STeVe

 

[Paul Rubin]

So it seems like you're really arguing for raising exceptions in all
these situations. That would actually be fine with me since I never
use bools as ints, but I suspect getting it past python-dev will be an
uphill battle since it will break large chunks of code.

We had a huge discussion of this stuff when bools were introduced
in Python 2.3 or thereabouts. The current system is about the
best way that doesn't break everything in sight. The weirdness
is basically a consequence of bools being an afterthought in Python.
Python has a long tradition of implicitly casting other values to
bool, e.g. strings, lists, sets etc. are all false if empty, etc.

 

[Ben Finney]

It's much easier to explain to newcomers that *, + and - work on
True and False as if they were 1 and 0 than it is to introduce them
to a two element boolean algebra.

I've found exactly the opposite. When explaining that None is a value
that is not equal to any other, and that is a useful property, I've
received little confusion. Whereas when someone discovers that
arithmetic works on True and False as if they were numbers, or that
they are in fact *equal to* numbers, their function as boolean values
is much harder to explain.

So, it's for the purposes of explaining True and False to newcomers
(let alone keeping things clear when observing a program) that I would
welcome True and False as discrete values, so that when those values
are produced by an expression or function the result is clearly a
boolean value and not a faked one that is "really" an integer.

 

[Alexander Schmolck]

I mean, really, does anyone *expect* True+True to give 2, or that 2**True
even works, without having learnt that Python bools are ints? I doubt it.

Sure, why not? It's pretty damn useful. Ever heard of things like "indicator
functions", "Iverson brackets" etc.? Mathematicians have long been using
broken and cumbersome ad hoc notations to be able to do stuff like
``(x<b)*f(x)`` or ``-1**(i==j)`` (e.g. ``-1^{\delta_ij}``).

And python is not alone in this either; take matlab:

ans =

2

so certainly people coming from matlab to scipy *will* often expect True+True
== 2.

I'd claim that even if it weren't for backwards compatibility, python bools
should behave exactly as they are -- for a language that assigns a truth value
to instances of any type, this is the right behavior.

'as

 

[Steven D'Aprano]

Are they are aren't they?

I'm sorry, I can't parse that sentence.

print 1 in [True]
print 1 == True
print len(set(map(type, [1, 1])))
print len(set(map(type, [1, True])))

But I guess that you are probably trying to make the point that True and
False are instances of a _subtype_ of int rather than ints, under the
mistaken idea that this pedantry would matter. (If this is not the case,
then I apologize for casting aspersions.) However, you may notice that I
said _integers_, which is not the same thing as ints: the Python types
int and bool are both implementations of the mathematical "integer" or
"whole number".

 

[Steven D'Aprano]

I mean, really, does anyone *expect* True+True to give 2, or that
2**True even works, without having learnt that Python bools are ints? I
doubt it.

And the old Python idiom for an if...then...else expression:

["something", "or other"][True]

tends to come as a great surprise to most newbies. So I would argue
that bools being ints is more surprising than the opposite would be.

I disagree. I think you'd get just as many odd stares if:

True + True == True

Well, sure, if you're talking about people with no programming experience
whatsoever, or at least those who aren't at all familiar with the concept
of operator overloading. But we don't prohibit "foo" + "bar" because of
the existence of non-programmers.

But I think all you're really saying is that newbies don't expect things
like +, -, *, etc. to work with bools at all. Which I agree is probably
true.

No, what I am saying is that True and False being integers under the hood
is a surprising implementation detail. It has no _inherent_ benefit: it
is merely a practical way to bring bools into the language while
remaining backward compatible. For Python 2.x, that was the least bad
solution to the issue "oops, we should have included a bool type".

Python 3 is allowed to break backwards compatibility, and there is no
reason I can see to keep the current hack.

 

[Steven D'Aprano]

We had a huge discussion of this stuff when bools were introduced in
Python 2.3 or thereabouts. The current system is about the best way
that doesn't break everything in sight.

But Python 3 is allowed to break backwards compatibility, so that's no
longer a reason for keeping the current behaviour.

The weirdness is basically a
consequence of bools being an afterthought in Python. Python has a long
tradition of implicitly casting other values to bool, e.g. strings,
lists, sets etc. are all false if empty, etc.

No, that's not true. How could Python cast objects to bool before bool
existed?

What Python has is much more powerful: the concept of Something versus
Nothing. "x" and 4 and [23, "foo"] are all Something. "" and 0 and [] and
None are all Nothing. No cast, whether implicit or explicit, is needed.

What Python does is call the object's __nonzero__ method, if it has one,
otherwise it checks to see if the object has a non-zero length (if it has
a length), and otherwise the object is considered true.

From a purely functional perspective, bools are unnecessary in Python. I
think of True and False as syntactic sugar. But they shouldn't be
syntactic sugar for 1 and 0 any more than they should be syntactic sugar
for {"x": "foo"} and {}.