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

[Steven D'Aprano]

On Tue, 10 Jul 2007 23:42:01 +0200, Bjoern Schliessmann wrote:

Alan G Isaac wrote:

>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-ele...oolean_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.

[Steven D'Aprano]

On Tue, 10 Jul 2007 13:13:38 -0600, Steven Bethard wrote:

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...els e 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.
--
Steven.

[Paul Rubin]

Steven D'Aprano <st***@REMOVE.T HIS.cybersource .com.auwrites:

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(typ e, [1, 1])))
print len(set(map(typ e, [1, True])))

[Steven Bethard]

Steven D'Aprano wrote:

On Tue, 10 Jul 2007 13:13:38 -0600, Steven Bethard wrote:

>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...els e 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]

Steven Bethard <st************ @gmail.comwrite s:

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]

Steven Bethard <st************ @gmail.comwrite s:

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.

--
\ "Pinky, are you pondering what I'm pondering?" "Wuh, I think |
`\ so, Brain, but wouldn't anything lose its flavor on the bedpost |
_o__) overnight?" -- _Pinky and The Brain_ |
Ben Finney

[Steven D'Aprano]

On Tue, 10 Jul 2007 16:41:58 -0700, Paul Rubin wrote:

Steven D'Aprano <st***@REMOVE.T HIS.cybersource .com.auwrites:

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

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

print 1 in [True]
print 1 == True
print len(set(map(typ e, [1, 1])))
print len(set(map(typ e, [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.

[Steven D'Aprano]

On Tue, 10 Jul 2007 17:47:47 -0600, Steven Bethard wrote:

>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...els e 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.

[Steven D'Aprano]

On Tue, 10 Jul 2007 16:56:36 -0700, Paul Rubin wrote:

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 {}.
--
Steven.

[Rustom Mody]

Considering bools as ints --
Pros: The ALU of any computer uses boolean gates to build an
arithmetic functions. Therefore considering the base type of ints and
bools to be (strings of) bits seems natural

Cons: This comes from the pioneering work of Dijkstra and his coworkers)
The distributive law (one of them) in boolean algebra looks like this:
a /\ (b \/ c) = (a/\b) \/ (a/\c)

which becomes simpler to read and type and more familiar as
a(b+c) = ab + ac

So far so good. However its dual is
a\/(b/\c) = (a\/b) /\ (a\/c)

which in arithmetic notation becomes
a + bc = (a+b)(a+c)

This is sufficiently unintuitive and unnatural that even people
familiar with boolean algebra dot get it (so Dijkstra, Gries etc
claim)

Boolean algebra is perfectly dual, arithmetic is not. That is why we
need logical connectives 'and' and 'or' and dont somehow fudge along
with + and *. Therefore True and False should belong with 'and', 'or'
and 0,1 should belong with +,*