Albert van der Horst wrote:
>>I guess I never thought about it, but there isn't an 'xor' operator to
>>go along with 'or' and 'and'. Must not be something I need very often.
>
> There is. <> applied to booleans is xor.
>
Best to get into the habit of using '!=' otherwise you'll find Python 3.x
I'm not not touching you!
--
http://mail.python.org/mailman/listinfo/python-list
In article <9142usf51...@mid.individual.net>,
Gregory Ewing wrote:
>Chris Angelico wrote:
>
>> Remind me some day to finish work on my "ultimate programming
>> language", which starts out with a clean slate and lets the programmer
>> define his own operators and everything.
>
>Didn't someone alre
In article ,
Grant Edwards wrote:
>
>On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes wrote:
>> Am 18.04.2011 21:58, schrieb John Nagle:
>>> ?? ?? This is typical for languages which backed into a "bool" type,
>>> rather than having one designed in. ??The usual result is a boolean
>>> type with
Jean-Paul Calderone wrote:
Also boolean xor is the same as !=.
Only if you have booleans. Even without short circuiting,
a boolean xor operator could provide the service of
automatically booling things for you (is that a word?).
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-li
On Apr 19, 10:23 am, Grant Edwards wrote:
> On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes wrote:
> > Am 18.04.2011 21:58, schrieb John Nagle:
> >> ?? ?? This is typical for languages which backed into a "bool" type,
> >> rather than having one designed in. ??The usual result is a boolean
> >>
On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes wrote:
> Am 18.04.2011 21:58, schrieb John Nagle:
>> ?? ?? This is typical for languages which backed into a "bool" type,
>> rather than having one designed in. ??The usual result is a boolean
>> type with numerical semantics, like
>>
>> ??>>> Tru
On Tue, 2011-04-19 at 19:00 +1000, Chris Angelico wrote:
> On Tue, Apr 19, 2011 at 6:43 PM, Steven D'Aprano
> wrote:
> > but I don't see how
> >
> > (arbitrary expression) + (another expression) + ... + (last expression)
> >
> > can have any guarantees applied. I mean, you can't even guarantee tha
On Tue, Apr 19, 2011 at 6:43 PM, Steven D'Aprano
wrote:
> but I don't see how
>
> (arbitrary expression) + (another expression) + ... + (last expression)
>
> can have any guarantees applied. I mean, you can't even guarantee that
> they won't raise an exception. Can you explain what you mean?
What
On Tue, 19 Apr 2011 16:26:50 +1000, Chris Angelico wrote:
> On Tue, Apr 19, 2011 at 4:23 PM, Kushal Kumaran
> wrote:
>>> if a + b + c + d != 1:
>>> raise ValueError("Exactly one of a, b, c or d must be true.")
>>>
>>>
>> Unless you're sure all of a, b, c, and d are boolean values, an int
>> wi
On Tue, Apr 19, 2011 at 4:23 PM, Kushal Kumaran
wrote:
>> if a + b + c + d != 1:
>> raise ValueError("Exactly one of a, b, c or d must be true.")
>>
>
> Unless you're sure all of a, b, c, and d are boolean values, an int
> with a negative value slipping in could result in the sum equaling 1,
>
On Tue, Apr 19, 2011 at 7:09 AM, Christian Heimes wrote:
> Am 18.04.2011 21:58, schrieb John Nagle:
>> This is typical for languages which backed into a "bool" type,
>> rather than having one designed in. The usual result is a boolean
>> type with numerical semantics, like
>>
>> >>> True + T
Am 18.04.2011 21:58, schrieb John Nagle:
> This is typical for languages which backed into a "bool" type,
> rather than having one designed in. The usual result is a boolean
> type with numerical semantics, like
>
> >>> True + True
> 2
I find the behavior rather useful. It allows multi-xor
Chris Angelico wrote:
Remind me some day to finish work on my "ultimate programming
language", which starts out with a clean slate and lets the programmer
define his own operators and everything.
Didn't someone already do that and call it "lisp"? :-)
--
Greg
--
http://mail.python.org/mailman/
John Nagle wrote:
Pascal got this right. (A nice feature of Pascal
was that "packed array of boolean" was a bit array).
C, which originally lacked a "bool" type, got it wrong.
So did Python.
If Python had had a boolean type from the beginning, it
probably wouldn't have been a subclass of in
On 4/17/2011 5:12 PM, Gregory Ewing wrote:
Chris Angelico wrote:
Well, of course you can always implement bool as an int;
Which Python used to do once upon a time -- and still does
in a way, because bool is a subclass of int.
The bool type was added mainly to provide a type that prints
out a
Steven D'Aprano wrote:
> So in Python 2.2, Python introduced two new built-in names, True and
> False, with values 1 and 0 respectively:
>
> [steve@sylar ~]$ python2.2
> Python 2.2.3 (#1, Aug 12 2010, 01:08:27)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
> Type "help", "copyright", "cre
Le 18/04/2011 10:33, Raymond Hettinger a écrit :
# --
def bool_equivalent(x):
return True if x else False
It's faster to write:
def bool_equivalent(x):
return not not x
faster and ... smarter ;)
--
http://mail.python.org/mailman/listinfo/pyth
On Apr 16, 1:24 pm, candide wrote:
> Consider the following code :
>
> # --
> def bool_equivalent(x):
> return True if x else False
It's faster to write:
def bool_equivalent(x):
return not not x
Raymond
--
http://mail.python.org/mailman/listinfo/py
On Sun, 17 Apr 2011 22:49:41 -0700, Chris Rebert wrote:
>> Pro: You can do anything.
>> Con: You can do anything.
>
> I think someone already beat you to it. They call their invention
> "Lisp". :-P
Also Forth.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Apr 18, 2011 at 3:49 PM, Chris Rebert wrote:
>> Pro: You can do anything.
>> Con: You can do anything.
>
> I think someone already beat you to it. They call their invention "Lisp". :-P
Bah! Lisp comes, out of the box, with far too many features! No no no.
If you want the + operator to add
On Sun, Apr 17, 2011 at 9:53 PM, Chris Angelico wrote:
> On Mon, Apr 18, 2011 at 2:40 PM, Ned Deily wrote:
>> Even better:
>> $ python2.7 -c 'False = True; print False'
>> True
>
> http://bofh.ch/bofh/bofh13.html
>
>> Alas:
>> $ python3 -c 'False = True; print(False)'
>> File "", line 1
>> Synt
On Mon, Apr 18, 2011 at 2:40 PM, Ned Deily wrote:
> Chris Angelico:
>> Dave Angel:
>> bool = int
>> Any language that allows you to do this is either awesome or
>> terrifying. Come to think of it, there's not a lot of difference.
>
> Even better:
> $ python2.7 -c 'False = True; print False'
Chris Angelico:
> Dave Angel:
> bool = int
> Any language that allows you to do this is either awesome or
> terrifying. Come to think of it, there's not a lot of difference.
Even better:
$ python2.7 -c 'False = True; print False'
True
Alas:
$ python3 -c 'False = True; print(False)'
File "
On Mon, Apr 18, 2011 at 12:46 PM, Dave Angel wrote:
> He didn't say that the function will call the bool() type (constructor), but
> that it will use the bool type;
Actually, he did say exactly that
> Any boolean expression is going to be _calling the built-in ‘bool’ type
> constructor_
(undersc
On Mon, Apr 18, 2011 at 11:46 AM, Dave Angel wrote:
bool = int
>
Any language that allows you to do this is either awesome or
terrifying. Come to think of it, there's not a lot of difference.
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
On 01/-10/-28163 02:59 PM, Daniel Kluev wrote:
On Sun, Apr 17, 2011 at 8:38 AM, Ben Finney wrote:
It won't look up the *name* ‘bool’, but it will use that object. Any
boolean expression is going to be calling the built-in ‘bool’ type
constructor.
So the answer to the OP's question is no: the f
On Mon, Apr 18, 2011 at 10:22 AM, Steven D'Aprano
wrote:
types = [str, complex, float, bool]
[f(x) for f, x in zip(types, (1, 2, 3, 4))]
> ['1', (2+0j), 3.0, True]
I believe this one would work fine with a function defined as per OP -
zip takes callables, which could be types or functio
Daniel Kluev writes:
> Actually, as I was curious myself, I've checked sources and found that
> `True if x else False` will _not_ call bool(), it calls
> PyObject_IsTrue() pretty much directly.
Sure. By ‘bool(x)’ I'm referring only to the implementation inside that
constructor.
> So technically
On Mon, 18 Apr 2011 01:22:59 +0200, candide wrote:
> > What is the
> > “shortcut” you refer to?
>
> bool(x) is nothing more than a shortcut for the following expression :
> True if x else False.
"Nothing more"? That's completely incorrect. bool is a type object, not
an expression, so you can
Chris Angelico wrote:
Well, of course you can always implement bool as an int;
Which Python used to do once upon a time -- and still does
in a way, because bool is a subclass of int.
The bool type was added mainly to provide a type that prints
out as 'True' or 'False' rather than 1 or 0. This
candide wrote:
bool(x) is nothing more than a shortcut for the following expression :
True if x else False.
It's a much shorter and easier-to-read shortcut.
Also keep in mind that if-else expressions are quite a recent
addition to the language.
Before that, we had 'not not x' as another equi
candide writes:
> Le 17/04/2011 11:46, Ben Finney a écrit :
> > What is the “shortcut” you refer to?
>
> bool(x) is nothing more than a shortcut for the following expression :
> True if x else False.
We're going around in circles. I've already pointed out that ‘bool(x)’
is what the expression yo
On Sun, Apr 17, 2011 at 8:38 AM, Ben Finney wrote:
> It won't look up the *name* ‘bool’, but it will use that object. Any
> boolean expression is going to be calling the built-in ‘bool’ type
> constructor.
>
> So the answer to the OP's question is no: the function isn't equivalent
> to the type, b
Le 17/04/2011 11:46, Ben Finney a écrit :
> candide writes:
>
>> First because I was doubting the true interest of the bool() type. In
>> fact, it appears that it's _semantically_ a shortcut for
>> True if x else False.
>
> That bends my brain. Both ‘True’ and ‘False’ are instances of the ‘bool’
On Sun, Apr 17, 2011 at 7:38 PM, candide wrote:
> I could't imagine a builtin function having a so trivial implementation.
As it was pointed out, its not function, its type,
SETBUILTIN("bool", &PyBool_Type);
While its __new__ is indeed trivial (in essence, it just calls
PyObject
candide writes:
> First because I was doubting the true interest of the bool() type. In
> fact, it appears that it's _semantically_ a shortcut for
> True if x else False.
That bends my brain. Both ‘True’ and ‘False’ are instances of the ‘bool’
type. So of course the ‘bool’ constructor will retur
On Sun, Apr 17, 2011 at 6:38 PM, candide wrote:
> I also try to consider how essential the bool() type is.
> Again compare with int() or str() types.
Well, of course you can always implement bool as an int; C has done
this for decades, and it hasn't killed it. You can also implement
integers as s
Le 17/04/2011 04:39, Ben Finney a écrit :
Why do you need to know? (I should have asked that question earlier.)
First because I was doubting the true interest of the bool() type. In
fact, it appears that it's _semantically_ a shortcut for
True if x else False. I could't imagine a builtin f
candide writes:
> Le 16/04/2011 23:13, Ben Finney a écrit :
>
> > The ‘bool’ built-in is not a function.
>
> Oops, unfortunate confusion!! but built-in types and built-in
> functions are sometimes so similar from the user's point of view ;)
Yes, intentionally so, because:
> All the same, you ca
On Sat, Apr 16, 2011 at 4:51 PM, candide wrote:
> Le 16/04/2011 23:38, Ben Finney a écrit :
>
>> So the answer to the OP's question is no: the function isn't equivalent
>> to the type,
>
> Can bool() type and bool_equivalent() function return different values ?
No. The distinction being drawn is
Le 16/04/2011 23:13, Ben Finney a écrit :
The ‘bool’ built-in is not a function.
>>> type(bool)
Oops, unfortunate confusion!! but built-in types and built-in functions
are sometimes so similar from the user's point of view ;)
All the same, you can notice that the official doc
Le 16/04/2011 23:38, Ben Finney a écrit :
So the answer to the OP's question is no: the function isn't equivalent
to the type,
Can bool() type and bool_equivalent() function return different values ?
because the OP's ‘bool_equivalent’ function necessarily
uses the built-in ‘bool’ type, whi
Chris Rebert writes:
> That is, `True if x else False` conceptually gets compiled down to
> `True if bool(x) == 1 else False` (but without doing a run-time lookup
> of "bool").
It won't look up the *name* ‘bool’, but it will use that object. Any
boolean expression is going to be calling the buil
candide writes:
> Is the bool_equivalent() function really equivalent to the bool()
> built-in function ?
The ‘bool’ built-in is not a function.
>>> type(bool)
--
\ “Generally speaking, the errors in religion are dangerous; |
`\those in philosophy only ridiculous.” —D
On Sat, Apr 16, 2011 at 1:24 PM, candide wrote:
> Consider the following code :
>
> # --
> def bool_equivalent(x):
> return True if x else False
>
>
> # testing ...
>
> def foo(x):
> return 10*x
>
> class C:
> pass
>
> for x in [42, ("my","baby"), "baob
Consider the following code :
# --
def bool_equivalent(x):
return True if x else False
# testing ...
def foo(x):
return 10*x
class C:
pass
for x in [42, ("my","baby"), "baobab", max, foo, C] + [None, 0, "", [],
{},()]:
print bool(x)==bool
47 matches
Mail list logo
