bool behavior in Python 3000?

[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 +,*

 

[Stargaming]

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

[snip]

No, I think Bjoern just wanted to point out that all those binary
boolean operators already work *perfectly*. You just have to emphasize
that you're doing boolean algebra there, using `bool()`.
"Explicit is better than implicit."

 

[Alan Isaac]

I think Bjoern just wanted to point out that all those binary
boolean operators already work *perfectly*.

True

But reread Steven.

Cheers,
Alan Isaac

 

[Alan Isaac]

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

<type 'bool'>

Cheers,
Alan Isaac

 

[Rob Wolfe]

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

But `bools` are usefull in some contexts. Consider this:
-1

At first look you can see that `cmp` does not return boolean value
what not for all newbies is so obvious.

Rob

 

[Miles]

True

What boolean operation does '-' represent?

 

[Stargaming]

True

But reread Steven.

Cheers,
Alan Isaac

What would you expect this operation to return then?
The * and + operations described in the previously mentioned document
(http://en.wikipedia.org/wiki/Two-element_Boolean_algebra) work as you'd
expect them to do, if you explicitly state "hey, this should be a
boolean algebra operation". And that's okay in my opinion. If you could
describe what's wrong about that result, we could probably help better.

Steven just suggests another (IMO totally unrelated) implementation of
bool types. A point that Bjoern does not even touch here. Besides, his
implementations fails at the * operation.

Bjoern does not (sorry, if I say anything wrong, Bjoern) say the current
behaviour is right or wrong. He just says that you can make Python aware
of boolean algrebra utilizing `bool()` easily.

bool-ly,
Stargaming

 

[Steve Holden]

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

You can only cast aspersions in C, C# and similar languages. In Python
you'd have to explicitly convert the aspersions to some other type ;-)

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

 

[Alan Isaac]

What boolean operation does '-' represent?

Complementation.
And as usual, a-b is to be interpreted as a+(-b).
In which case the desired behavior is
False-True = False+(-True)=False+False = False

In response to Stargaming, Steve is making
a point about the incoherence of certain arguments,
not proposing an implementation.

Cheers,
Alan Isaac

 

[Alan Isaac]

Since it is seemingly ignored in most of the comments
on this thread, I just want to remind that PEP 285
http://www.python.org/dev/peps/pep-0285/
says this:

In an ideal world, bool might be better implemented as a
separate integer type that knows how to perform mixed-mode
arithmetic.

I mentioned Python 3000 since that is an opportunity for an ideal world.

Cheers,
Alan Isaac

 

[Steven Bethard]

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.

Remember that while Python 3 is allowed to break backwards
compatibility, it's only supposed to do it when there are concrete
benefits. Clearly there are existing use cases for treating bools like
ints, e.g. from Alexander Schmolck's email:

(x < b) * f(x)
-1 ** (i == j)

If you want to remove this functionality, you're going to need to
provide some new use cases that it satisfies that are clearly more
important than these existing ones.

STeVe

 

[aaron.watters]

But `bools` are usefull in some contexts. Consider this:


-1

At first look you can see that `cmp` does not return boolean value
what not for all newbies is so obvious.

Excellent point! And as long as we have them I
agree with Alan that the boolean data type should
implement real boolean algebra with respect to +, *, and ~,
for example supporting operator precedence appropriately
(versus using and, or, not) and also correctly
implementing DeMorgan's laws and other property's of
boolean algebra

~(a*b) == ~a + ~b

etcetera.

1+True is bad practice and should be an error.

Anything else is false advertising
(and the java community has the patent on that
methodology :c) ).

-- Aaron Watters

===
Why does a giraffe have such a long neck?
Because its head is so far from its body!

 

[Marc 'BlackJack' Rintsch]

But `bools` are usefull in some contexts. Consider this:

-1

At first look you can see that `cmp` does not return boolean value
what not for all newbies is so obvious.

Sorry I fail to see your point!? What has ``==`` to do with `cmp()` here?
The return of `cmp()` is an integer that cannot and should not be seen as
boolean value.

Ciao,
Marc 'BlackJack' Rintsch

 

[Stargaming]

Complementation.
And as usual, a-b is to be interpreted as a+(-b).
In which case the desired behavior is
False-True = False+(-True)=False+False = False

I always thought, at least in a Python context, A-B would trigger
A.__sub__(B), while A+(-B) triggers A.__add__(B.__neg__()). A better
choice could be A+~B (A.__add__(B.__invert__())) because it's always
unary (and IMO slightly more visible).

In response to Stargaming, Steve is making
a point about the incoherence of certain arguments,
not proposing an implementation.

Why should it be incoherent? Bjoern is pointing out an important aspect
of how Python handles binary algebra (correctly). In contrast, Steven
tries to invert his argument. Following, I showed why Steven's proof is
wrong because his implementation fails at some aspects where the current
one works. So I cannot see how Bjoern's argument is either wrong or not
relevant.

 

[Peter Otten]

How could Python cast objects to bool before bool
existed?

Time machine?

Sorry, I couldn't resist.

Peter

 

[Bruno Desthuilliers]

Steven Bethard a écrit :
(snip)

Remember that while Python 3 is allowed to break backwards
compatibility, it's only supposed to do it when there are concrete
benefits. Clearly there are existing use cases for treating bools like
ints, e.g. from Alexander Schmolck's email:

(x < b) * f(x)
-1 ** (i == j)

Both can be cleanly handled using int():

int(x < b) * f(x)
-1 ** int(i == j)

Not that I have any clear opinion on the topic FWIW.

 

[Rob Wolfe]

Sorry I fail to see your point!? What has ``==`` to do with `cmp()` here?
The return of `cmp()` is an integer that cannot and should not be seen as
boolean value.

Before `bool` appeared it looked like this:
1

Wich result is boolean value?

Rob

 

[Bruno Desthuilliers]

Steven D'Aprano a écrit :
(snip)

I mean, really, does anyone *expect* True+True to give 2, or that 2**True
even works,

I may be biased since I learned C before Python and learned Python
before it had a Boolean type, but I'd think that having False==0 and
True==1 is not that surprising for most programmers.

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.

This idiom should slowly disappear now we have a clean syntax for such
expressions.

So I would argue that
bools being ints is more surprising than the opposite would be.

I suppose this mostly have to do with one's background.

 

[Ed Leafe]

No, I think Bjoern just wanted to point out that all those binary
boolean operators already work *perfectly*. You just have to emphasize
that you're doing boolean algebra there, using `bool()`.
"Explicit is better than implicit."

I think that the assignability to the names 'True' and 'False' is
incorrect, or at the very least subject to all sorts of odd results.
Look at this:
False

Yeah, I know: "Doctor, it hurts when I do this". Doc: "So don't do
that!". I haven't kept up with all the Python 3000 docs, so does
anyone know if True and False will become true keywords, and whether
oddball stuff like the above will no longer be possible?

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

 

[Nick Craig-Wood]

Complementation.
And as usual, a-b is to be interpreted as a+(-b).
In which case the desired behavior is
False-True = False+(-True)=False+False = False

If you want to do algebra with bools in python then use the logical
operators (and or not) and not the arithmetical operators.

Eg
False