bool behavior in Python 3000?

[tah]

Re: bool behavior in Python 3000?

On Jul 11, 1:30 pm, Nick Craig-Wood <n...@craig-wood.comwrote:

Alan Isaac <ais...@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

Let me comment on what I suspect is Alan's Hidden Agenda (tm). Since
this question surfaced earlier on the numpy list, I suspect that part
of the motivation here has to do with trying to come up with a natural
way to work with arrays of booleans. The operators and,or,not don't
work for this purpose since they can't be overloaded to return an
arbitrary value. You can almost make this work with &,|,^:

>>a = np.array([True, False, False])
>>b = np.array([True, True, False])
>>a & b

array([ True, False, False], dtype=bool)

>>a | b

array([ True, True, False], dtype=bool)

>>a ^ b

array([False, True, False], dtype=bool)

This is meshes well with the behavior of True and False:

>>True & True

True

>>True | True

True

>>True ^ True

False

This doesn't leave you with anything equivalent to 'not' however. Or
nothing consistent. Currently '~a' will complement a boolean array,:

>>~a

array([False, True, True], dtype=bool)

However that's less than ideal since it doesn't mesh up with the
behavior of booleans on their own:

>>~True

-2

That's potentially confusing. It's not any skin of my nose since I
use, and will likely continue to use, boolean arrays in only the most
rudimentary ways. However, I thought I'd offer some additional
context.

-tim

[Paul Rubin]

Re: bool behavior in Python 3000?

tah <tim.hochberg@g mail.comwrites:

This doesn't leave you with anything equivalent to 'not' however. Or
nothing consistent. Currently '~a' will complement a boolean array,:
>

>~a

array([False, True, True], dtype=bool)

Can you use operator.not_(a ) ?

[Stargaming]

Re: bool behavior in Python 3000?

Steven D'Aprano schrieb:

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

You're missing like 400 bool(...) is True constructs there! Fatal error,
recursion depth reached. Aww!

[=?ISO-8859-15?Q?Nis_J=F8rgensen?=]

Re: bool behavior in Python 3000?

Alan Isaac skrev:

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.

You forgot to quote this bit:

4) Should we strive to eliminate non-Boolean operations on bools
in the future, through suitable warnings, so that for example
True+1 would eventually (in Python 3000) be illegal?

=No.

There's a small but vocal minority that would prefer to see
"textbook" bools that don't support arithmetic operations at
all, but most reviewers agree with me that bools should always
allow arithmetic operations.

Nis

[Ben Finney]

Re: bool behavior in Python 3000?

"Terry Reedy" <tjreedy@udel.e duwrites:

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/

I assume you're referring to:

6) Should bool inherit from int?

=Yes.

In an ideal world, bool might be better implemented as a
separate integer type that knows how to perform mixed-mode
arithmetic. However, inheriting bool from int eases the
implementation enormously [...further explanation...]

I accept Guido's explanation in the PEP, that the implementation is
made much easier, as an explanation of why bool inherits from int. I
haven't seen people here expressing that they want the opposite.

To my mind the more fundamental issue is this one:

4) Should we strive to eliminate non-Boolean operations on bools
in the future, through suitable warnings, so that for example
True+1 would eventually (in Python 3000) be illegal?

=No.

There's a small but vocal minority that would prefer to see
"textbook" bools that don't support arithmetic operations at
all, but most reviewers agree with me that bools should always
allow arithmetic operations.

Frustratingly, unlike the above point about inheritance, the PEP gives
no explanation of why the answer to this is "No". All we get is "most
reviewers agree", with no explanation of *why*.

So, I'm left with the points already made in this thread as to why the
answer should be "yes", and no source online for an official
explanation of the "no".

--
\ "I don't like country music, but I don't mean to denigrate |
`\ those who do. And for the people who like country music, |
_o__) denigrate means 'put down'." -- Bob Newhart |
Ben Finney

[Bjoern Schliessmann]

Re: bool behavior in Python 3000?

Alan Isaac wrote:

Bjoern Schliessmann wrote:

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

>>>type(True)

<type 'bool'>

Thanks anyway, but I remembered it shortly after sending. Thus the
cancel (seems to have failed a bit).

Regards,


Björn

--
BOFH excuse #384:

it's an ID-10-T error

[Bjoern Schliessmann]

Re: bool behavior in Python 3000?

Steven D'Aprano wrote:

It seems to me that you deliberately misunderstood him.

I know for sure I didn't.

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?

Kindly excuse me bothering You.


Björn

--
BOFH excuse #419:

Repeated reboots of the system failed to solve problem

[Alexander Schmolck]

Re: bool behavior in Python 3000?

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

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.

Just because it looks funny to you doesn't mean it is a hack. It turns out
that many mathemtical formulas can be written more clearly using this notation
(see e.g. at knuth et al's "concrete mathematics"), and in mathematics limited
and often ambiguous ad hoc notation that is neatly subsumed by this scheme is
widely established.

And I don't think adding int is an improvement: ``(x < b) * f(x)`` is plenty
clear (not easily misread as something else and, I believe, not even
particularly difficult to figure out even for mediocre python programmers) but
adding padding just obscures formula structure. Of course it doesn't in the
above examples with less than half a dozen terms, but IMO for something longer
the int-litter, even it may be soothing the psyches of the anally retentive,
is counterproducti ve.

'as

[Alan Isaac]

Re: bool behavior in Python 3000?

Alan Isaac skrev:

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

Nis Jørgensen wrote:

You forgot to quote this bit: [4)]

Actually not. That is a different point.
Ben seems bothered by this, but not me.
I do not mind that True+1 is 2.
I won't do it, but I do not object to it
being possible.

I do not like that True+True is 2.
I do not like that bool(False-True) is True.
I do not like that True and False are assignable,
which clearly begs for bugs to pass unseen.

>>True, False = False, True
>>print True, False

False True

Who can like that????

I also generally agree with Steve, whose points
keep being twisted beyond recognition.

Also, tah is right about my underlying interest
in arrays of bools (and more specifically,
boolean matrices).

I think Python 3000 is the right time to reconsider
the "ideal world" that Guido mentions in PEP 285.

Cheers,
Alan Isaac

[Miles]

Re: bool behavior in Python 3000?

On Jul 12, 8:37 pm, Alan Isaac <ais...@america n.eduwrote:

I do not like that bool(False-True) is True.

I've never seen the "A-B" used to represent "A and not B", nor have I
seen any other operator used for that purpose in boolean algebra,
though my experience is limited. Where have you seen it used?

What's wrong with 'and', 'or', and 'not'? I think that redefining *,
+, and - to return booleans would only encourage programmers to use
them as shortcuts for standard boolean operations--I'd hate to see
code like this:

>>if user.registered * (user.age 13) - user.banned: ...

I don't mind that arithmatic operations are _possible_ with bools, but
I would strongly prefer to see the boolean keywords used for
operations on booleans.

-Miles

[Bruno Desthuilliers]

Re: bool behavior in Python 3000?

Steven D'Aprano a écrit :
(snip)

It makes more sense to explicitly cast bools to ints

s/cast bools to ints/build ints from bools/

AFAICT, there's no such thing as typecast in Python.

[Bruno Desthuilliers]

Re: bool behavior in Python 3000?

Miles a écrit :

On Jul 12, 8:37 pm, Alan Isaac <ais...@america n.eduwrote:

>I do not like that bool(False-True) is True.

>
I've never seen the "A-B" used to represent "A and not B", nor have I
seen any other operator used for that purpose in boolean algebra,
though my experience is limited. Where have you seen it used?

I've personnaly seen the usual arithmatic operators used for boolean
algebra in quite a lot of papers covering the topic - but I've always
had to translate them to more common boolean ops to understand these
papers.

What's wrong with 'and', 'or', and 'not'? I think that redefining *,
+, and - to return booleans would only encourage programmers to use
them as shortcuts for standard boolean operations--I'd hate to see
code like this:

>>>if user.registered * (user.age 13) - user.banned: ...

>

OMG ! Lord have mercy ! St Guido, save us !

I don't mind that arithmatic operations are _possible_ with bools, but
I would strongly prefer to see the boolean keywords used for
operations on booleans.

+10

[ahlongxp]

Re: bool behavior in Python 3000?

On Jul 11, 5:36 am, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n.. .@spamgourmet.c omwrote:

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

check this out.

>>doespythonroc k = True
>>print type(doespython rock)

<type 'bool'>

>>>

--
ahlongxp

Software College,Northea stern University,Chin a
ahlongxp@gmail. com

http://www.herofit.cn