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

[Bjoern Schliessmann]

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]

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]

Steven D'Aprano <st***@REMOVE.THIS.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 counterproductive.

'as

[Alan Isaac]

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]

On Jul 12, 8:37 pm, Alan Isaac <[e-mail]:

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]

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]

Miles a écrit :

On Jul 12, 8:37 pm, Alan Isaac <[e-mail]:

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

On Jul 11, 5:36 am, Bjoern Schliessmann <usenet-
[e-mail]:

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

check this out.

>>doespythonrock = True
print type(doespythonrock)

<type 'bool'>

>>>

--
ahlongxp

Software College,Northeastern University,China
ah******@gmail.com
http://www.herofit.cn