bool behavior in Python 3000?

[Marc 'BlackJack' Rintsch]

Re: bool behavior in Python 3000?

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]

Re: bool behavior in Python 3000?

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]

Re: bool behavior in Python 3000?

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]

Re: bool behavior in Python 3000?


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]

Re: bool behavior in Python 3000?

Steven D'Aprano wrote:

How could Python cast objects to bool before bool
existed?

Time machine?

Sorry, I couldn't resist.

Peter

[Bruno Desthuilliers]

Re: bool behavior in Python 3000?

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]

Re: bool behavior in Python 3000?

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]

Re: bool behavior in Python 3000?

Alan Isaac <aisaac@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 <nick@craig-wood.com-- http://www.craig-wood.com/nick

[Terry Reedy]

Re: bool behavior in Python 3000?


"Ed Leafe" <ed@leafe.comwr ote in message
news:C5AEB4C0-273B-411F-B14E-2B45E0881549@le afe.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]

Re: bool behavior in Python 3000?

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

[Steve Holden]

Re: bool behavior in Python 3000?

Terry Reedy wrote:

"Ed Leafe" <ed@leafe.comwr ote in message
news:C5AEB4C0-273B-411F-B14E-2B45E0881549@le afe.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.
>

But of course None was assignable until (?) 2.3 and then became formally
constant, so it was no longer possible to assign to it or even shadow it
in a local namespace. So much for that kind of backward compatibility!

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

[Terry Reedy]

Re: bool behavior in Python 3000?

In reply to various current discussants: there was a long discussion here
(clp) of similar points of view when bool was introduced. In Guido's
opinion (and mine, but his counts 100x), the positive benefits of the
current implementation are greater than the net positive benefits of a
'pure' type. See

http://www.python.org/dev/peps/pep-0285/

tjr

[Paul Rubin]

Re: bool behavior in Python 3000?

Steve Holden <steve@holdenwe b.comwrites:

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

But of course None was assignable until (?) 2.3 and then became
formally constant, so it was no longer possible to assign to it or
even shadow it in a local namespace. So much for that kind of backward
compatibility!

None was present in the language for a long time before 2.3 though,
and any code that actually assigned to it was asking for trouble.
True and False didn't exist til recently and it was common for
programs to define them.

[Steven D'Aprano]

Re: bool behavior in Python 3000?

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.

Agreed. Syntactic sugar is useful, even though it is unnecessary. I'm not
against having bools. I just want them to be Booleans, not dicts, or
lists, or sets, or even integers.



--
Steven.

[Steven D'Aprano]

Re: bool behavior in Python 3000?

On Wed, 11 Jul 2007 07:14:53 -0600, Steven Bethard wrote:

Steven D'Aprano wrote:

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

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

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

You have cause and effect confused here. Expressions like (i == j) used
to return 0 and 1, and it was to avoid breaking hacks like the above
that bools were implemented as a subclass of int, not because being
able to write the above was a specific feature requested.

In the hypothetical bright new world of Python with bools that are
actually bools, the above are good cases for explicit being better than
implicit:

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

It makes more sense to explicitly cast bools to ints when you want to
do integer arithmetic on them, rather than explicitly casting bools to
bools to do boolean arithmetic! I feel strongly enough about this that I
believe that being able to write (x < b) * f(x) is a DISADVANTAGE -- it
gives me a real WTF moment to look at the code.

In some hypothetical world where backwards compatibility was not an
issue, where bools had already existed, if somebody had specifically asked
for bools to become ints so they could write (x < b) * f(x), I have every
confidence that their request would have been denied, and they would have
been told to explicitly cast the bool to an int. As they should.



--
Steven.