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

[Marc 'BlackJack' Rintsch]

On Wed, 11 Jul 2007 00:37:38 -0700, Rob Wolfe wrote:

Steven D'Aprano wrote:

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

True

>>>cmp(1, 1)

0

>>>1 == 2

False

>>>cmp(1, 2)

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

Alan Isaac schrieb:

Miles wrote:

>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+Fal se = False

I always thought, at least in a Python context, A-B would trigger
A.__sub__(B), while A+(-B) triggers A.__add__(B.__n eg__()). 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.

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

Marc 'BlackJack' Rintsch wrote:

On Wed, 11 Jul 2007 00:37:38 -0700, Rob Wolfe wrote:

Steven D'Aprano wrote:

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

True

>>cmp(1, 1)

0

>>1 == 2

False

>>cmp(1, 2)

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

Before `bool` appeared it looked like this:

>>1 == 1

1

>>cmp(2, 1)

1

Wich result is boolean value?

Rob

[Peter Otten]

Steven D'Aprano wrote:

How could Python cast objects to bool before bool
existed?

Time machine?

Sorry, I couldn't resist.

Peter

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

On Jul 11, 2007, at 2:04 AM, Stargaming wrote:

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:

>>True, False

(True, False)

>>True = False
True, False

(False, False)

>>True == False

True

>>(True == False) == True

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]

Alan Isaac <ai****@america n.eduwrote:

Miles wrote:

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+Fal se = 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 or not True

False

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[Terry Reedy]

"Ed Leafe" <[e-mail] ote in message
news:C5******** *************** ***********@lea fe.com...
| 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.

It is necessary for 2.x to not break older code. I believe they will
somehow be reserved, like None, in 3.0.

tjr

[Steven D'Aprano]

On Wed, 11 Jul 2007 08:04:33 +0200, Stargaming wrote:

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

So we should always write things explicitly like:

if bool(bool(some_ condition) is True) is True:
first_line = str(some_string ).split(str("\n "))[int(0)]
n = int(int(len(lis t(some_list))) + int(1))
elif bool(bool(some_ condition) is False) is True:
f = float(math.sin( float(6.0)/float(math.pi)) )

instead of the less explicit code. I'll try to remember that, thank you
for the advice.

--
Steven