Does Py3k have an xor keyword? (I am using 2.6 due to NumPy.)
(Yes I know BDFL is planning a moratorium on syntax.)
S.M.
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
How often do you need the xor operator?
> It's even weirder because boolean objects do have a __xor__ method.
The reason for that is that they inherit from integers. That method is the
usual bitwise integer xor.
> Does Py3k have an xor keyword? (I am using 2.6 due to NumPy.)
No.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
Doesn't this look like a case for new syntax before the moratorium?
It would be nice for symmetry, but it would be infrequently used
compared to the other operators and is not strictly necessary as
logical XOR cannot and would not short-circuit, unlike logical AND and
OR.
Cheers,
Chris
--
http://blog.rebertia.com
Have you looked at the recent python-list thread starting at:
http://mail.python.org/pipermail/python-list/2009-July/188589.html
?
Mark
No the proper syntax is
>>>False ^ False
False
>>>False ^ True
True
>>>True ^ False
True
>>>True ^ True
False
1) Technically, an operator is *never* needed, as its just syntactic sugar.
2) It sure would make crypto code look prettier, as we rely on xor
operations extensively.
Geremy Condra
I think you are missing the point: ^ is bitwise or. Don't think we can
always go from bitwise to boolean operator by casting to bool. Xor is a
special case.
>>> bool(not True)
False
>>> bool(~True)
True
S.M.
Exactly. Therefore it makes sense to select the most often used operations
and add syntactic sugar for them. Boolean XOR is not one of them. (The
thread linked by Mark enumerates a fair number of equivalent spellings,
but the most important thing is that it's impossible to make the "xor"
behave equivalent to "and" and "or" in terms of short-circuiting and
returning one of the operands.)
> 2) It sure would make crypto code look prettier, as we rely on xor
> operations extensively.
We *do* have a bitwise xor.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
_______________________________________________
No, it wouldn't. Crypto uses the bitwise xor which we already have an operator
for: ^.
As I stated in the referenced thread, to me, the most compelling reason there is
no "xor" keyword to go with "and" and "or" is that one cannot make an xor that
shares the same short-circuiting behavior. Or the behavior of returning one of
the operand objects rather than a coerced bool. Without either of those
behaviors, there is little benefit to having a keyword operator where a trivial
one-liner will suffice.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
.. because it does: !=
>>> True != True
False
>>> True != False
True
>>> False != False
False
In 2.x you can even use <> if you like syntactic sugar. :-)
On arbitrary types a xor b is arguably bool(a) != bool(b) rather than
simple a != b, but it is rare enough to warrant additional syntax.
I thought I've seen this answered in an FAQ list somewhere.
Actually, I use it primarily in the public-key context, where bitwise
comparison doesn't make a whole lot of sense.
> As I stated in the referenced thread, to me, the most compelling reason
> there is no "xor" keyword to go with "and" and "or" is that one cannot make
> an xor that shares the same short-circuiting behavior. Or the behavior of
> returning one of the operand objects rather than a coerced bool. Without
> either of those behaviors, there is little benefit to having a keyword
> operator where a trivial one-liner will suffice.
I've always tried to avoid and/or in Python for exactly that behavior.
You're right that it would be confusing, though.
Geremy Condra
No, the moratorium (assuming it's accepted) starts retroactively the
day 3.1 was released.
--
--Guido van Rossum (python.org/~guido)
X xor Y evaluates to:
X if bool(X)==True and bool(Y)==False
Y if bool(Y)==True and bool(X)==False
False if bool(X)==Bool(Y)==True
Y if bool(X)==bool(Y)==False
The last case is analagous to X or Y evaluating to Y when
bool(X)==bool(Y)==False, e.g.
0 or [] == []
[] or 0 == 0
Admittedly there is an aestheically unpleasing asymmetry here.
But it means you could write code such as
Z = X xor Y
if Z:
<do something with Z>
# Z is known to be either X or Y
Of course, there is no evaluation short-circuiting.
Rob Cliffe
No you cannot always go from bitwise to logical, but in the xor case
it works, which is the case you were wanting to add syntax for. Just
because it is also bitwise syntax does not mean you cannot use it in
logical operations where it is intended to work.
The only benefit I see to adding xor is not having to cast items to a
bool before doing the test, which could be solved with no syntax
changes by adding the __xor__ method to the types you want to check,
though I think adding this to builtins would fall under the
moratorium.
could define __xor__ for all objects, except where the bitwise xor is
intended as
def __xor__(self, other):
return bool(self) ^ bool(other)
I've seen this in Java. But the field is different there, with no
operator overloading != is always be equivalent with logical XOR. I'm +0
on the proposal, for being very rarely needed.