On Jul 12, 8:37 pm, Alan Isaac [EMAIL PROTECTED] wrote:
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?
Miles a écrit :
On Jul 12, 8:37 pm, Alan Isaac [EMAIL PROTECTED] wrote:
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
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.
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 11, 5:36 am, Bjoern Schliessmann usenet-
[EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED]
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
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
Terry Reedy [EMAIL PROTECTED] writes:
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)
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
--
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
Steven D'Aprano [EMAIL PROTECTED] writes:
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
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
Steven D'Aprano wrote:
On Tue, 10 Jul 2007 23:42:01 +0200, Bjoern Schliessmann wrote:
Alan G Isaac wrote:
My preference would be for the arithmetic operations *,+,-
to be given the standard interpretation for a two element
boolean algebra:
Stargaming wrote:
I think Bjoern just wanted to point out that all those binary
boolean operators already work *perfectly*.
bool(False-True)
True
But reread Steven.
Cheers,
Alan Isaac
--
http://mail.python.org/mailman/listinfo/python-list
Bjoern Schliessmann wrote:
Is there any type named bool in standard Python?
type(True)
type 'bool'
Cheers,
Alan Isaac
--
http://mail.python.org/mailman/listinfo/python-list
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
On Jul 11, 2:50 am, Alan Isaac [EMAIL PROTECTED] wrote:
bool(False-True)
True
What boolean operation does '-' represent?
--
http://mail.python.org/mailman/listinfo/python-list
Alan Isaac schrieb:
Stargaming wrote:
I think Bjoern just wanted to point out that all those binary boolean
operators already work *perfectly*.
bool(False-True)
True
But reread Steven.
Cheers,
Alan Isaac
What would you expect this operation to return then?
The * and +
Steven D'Aprano wrote:
On Tue, 10 Jul 2007 16:41:58 -0700, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Pretending that False and True are just magic names for 0 and 1 might
be easier than real boolean algebra, but that puts the cart before
the horse. Functionality comes
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+False = False
In response to Stargaming, Steve is making
a point about the incoherence of certain
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
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
On Jul 11, 3:37 am, Rob Wolfe [EMAIL PROTECTED] wrote:
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.
Excellent
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
Steven D'Aprano wrote:
How could Python cast objects to bool before bool
existed?
Time machine?
Sorry, I couldn't resist.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
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
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+False = False
I always thought, at least in a Python context, A-B would
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
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) *
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
Alan Isaac [EMAIL PROTECTED] wrote:
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+False = False
If you want to do algebra with bools
Ed Leafe [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| 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
Terry Reedy wrote:
Ed Leafe [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| 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
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
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'
Steve Holden [EMAIL PROTECTED] writes:
| 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.
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
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.
On Jul 11, 1:30 pm, Nick Craig-Wood [EMAIL PROTECTED] wrote:
Alan Isaac [EMAIL PROTECTED] wrote:
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 =
tah [EMAIL PROTECTED] writes:
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) ?
--
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
--
http://mail.python.org/mailman/listinfo/python-list
Alan Isaac wrote:
Is there any discussion of having real booleans
in Python 3000?
I'm not sure how the bools we have now are not real.
Say something along the line of the numpy implementation for arrays
of type 'bool'?
What aspect of this do you want? A bool typecode for the stdlib array
Alan Isaac wrote:
Is there any discussion of having real booleans
in Python 3000?
The last I have seen is
http://mail.python.org/pipermail/python-3000/2007-January/005284.html
Hoping the bool type will be fixed will be fixed,
Do you care to explain what is broken?
Peter
--
Peter Otten wrote:
The last I have seen is
http://mail.python.org/pipermail/python-3000/2007-January/005284.html
OK. Thanks.
Do you care to explain what is broken?
I suppose one either finds coercion of arithmetic operations to int
to be odd/broken or does not. But that's all I meant.
Alan G Isaac wrote:
Do you care to explain what is broken?
I suppose one either finds coercion of arithmetic operations to int
to be odd/broken or does not. But that's all I meant.
My preference would be for the arithmetic operations *,+,-
to be given the standard interpretation for a
Do you care to explain what is broken?
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
If I understand this right, the biggest difference from
Alan Isaac wrote:
Hoping the bool type will be fixed will be fixed,
Is there any type named bool in standard Python?
Regards,
Björn
--
BOFH excuse #207:
We are currently trying a new concept of using a live mouse.
Unfortunately, one has yet to survive being hooked up to the
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
Alan Isaac [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| 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'?
As far as I know, there is no such discussion among the developers.
Clp
Michael Hoffman [EMAIL PROTECTED] writes:
Alan Isaac wrote:
Is there any discussion of having real booleans
in Python 3000?
I'm not sure how the bools we have now are not real.
I'm guessing that Alan is referring (at least in part) to this behaviour:
Python 2.4.4 (#2, Apr 5 2007,
On Tue, 10 Jul 2007 23:42:01 +0200, Bjoern Schliessmann wrote:
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
On Tue, 10 Jul 2007 13:13:38 -0600, Steven Bethard wrote:
It's much easier to explain to newcomers that *, + and - work on True
and False as if they were 1 and 0 than it is to introduce them to a two
element boolean algebra. So making this kind of change needs a pretty
strong motivation
Steven D'Aprano [EMAIL PROTECTED] writes:
Pretending that False and True are just magic names for 0 and 1 might be
easier than real boolean algebra, but that puts the cart before the
horse. Functionality comes first: Python has lists and dicts and sets
despite them not being ints, and somehow
Steven D'Aprano wrote:
On Tue, 10 Jul 2007 13:13:38 -0600, Steven Bethard wrote:
It's much easier to explain to newcomers that *, + and - work on True
and False as if they were 1 and 0 than it is to introduce them to a two
element boolean algebra. So making this kind of change needs a
Steven Bethard [EMAIL PROTECTED] writes:
So it seems like you're really arguing for raising exceptions in all
these situations. That would actually be fine with me since I never
use bools as ints, but I suspect getting it past python-dev will be an
uphill battle since it will break large
Steven Bethard [EMAIL PROTECTED] writes:
It's much easier to explain to newcomers that *, + and - work on
True and False as if they were 1 and 0 than it is to introduce them
to a two element boolean algebra.
I've found exactly the opposite. When explaining that None is a value
that is not
Steven D'Aprano [EMAIL PROTECTED] writes:
I mean, really, does anyone *expect* True+True to give 2, or that 2**True
even works, without having learnt that Python bools are ints? I doubt it.
Sure, why not? It's pretty damn useful. Ever heard of things like indicator
functions, Iverson brackets
On Tue, 10 Jul 2007 16:41:58 -0700, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Pretending that False and True are just magic names for 0 and 1 might
be easier than real boolean algebra, but that puts the cart before
the horse. Functionality comes first: Python has lists and
On Tue, 10 Jul 2007 17:47:47 -0600, Steven Bethard wrote:
I mean, really, does anyone *expect* True+True to give 2, or that
2**True even works, without having learnt that Python bools are ints? I
doubt it.
And the old Python idiom for an if...then...else expression:
[something, or
On Tue, 10 Jul 2007 16:56:36 -0700, Paul Rubin wrote:
We had a huge discussion of this stuff when bools were introduced in
Python 2.3 or thereabouts. The current system is about the best way
that doesn't break everything in sight.
But Python 3 is allowed to break backwards compatibility,
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
60 matches
Mail list logo
