Re: Differences of != operator behavior in python3 and python2 [ bug? ]
!= is explicit. There is no ambiguity that needs to be guessed. Which is why i said it thought X != Y is cleaner i guess i wasn't totally clear, I would write X != Y its because the OP preferred to use the other format I recommended that he made the operator ordering explicit. -- Nature abhors a virgin -- a frozen asset. -- Clare Booth Luce -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Tue, May 14, 2013 at 9:22 AM, Dave Angel da...@davea.name wrote: On 05/13/2013 06:53 PM, Mark Lawrence wrote: I much prefer the alternative for != but some silly people insisted that this be removed from Python3. Just how stupid can you get? So which special methods should the operator call? By rights it ought to call both __gt__ and __lt__ and return True if either of them is True. Why do you think that? After all, the != operator doesn't call __factorial__ and __assignment__ and return True if either is True, does it? ChrisA PS. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Tue, 14 May 2013 19:01:38 -0400, Dennis Lee Bieber wrote: On 14 May 2013 05:09:48 GMT, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info declaimed the following in gmane.comp.python.general: The operator comes from Pascal, where it was used as not equal since I thought it came from BASIC... http://en.wikipedia.org/wiki/Dartmouth_BASIC Ah, well apparently BASIC used it earlier, but I don't know whether it was an influence on Pascal (except as what not to do). -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Mon, 13 May 2013 05:23:16 +0600, Mr. Joe wrote:
I seem to stumble upon a situation where != operator misbehaves in
python2.x. Not sure if it's my misunderstanding or a bug in python
implementation. Here's a demo code to reproduce the behavior -
# -*- coding: utf-8 -*-
from __future__ import unicode_literals, print_function
class DemoClass(object):
def __init__(self, val):
self.val = val
def __eq__(self, other):
return self.val == other.val
x = DemoClass('a')
y = DemoClass('a')
print(x == y: {0}.format(x == y))
print(x != y: {0}.format(x != y))
print(not x == y: {0}.format(not x == y))
In python3, the output is as expected:
x == y: True x != y: False not x == y: False
In python2.7.3, the output is:
x == y: True x != y: True not x == y: False
Which is not correct!!
Thanks in advance for clarifications.
Regards,
TB
this looks to me like an issue with operator precidence
you code is evaluating as (Not x) == y
rather than not (x == y)
why the difference between 2.7 3.X is beyond my knowledge of the
language
The other explanations seem to detail things at low level but it is all
Greek to me
--
Nice guys finish last.
-- Leo Durocher
--
http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 13 May 2013 11:04, Alister alister.w...@ntlworld.com wrote: this looks to me like an issue with operator precidence you code is evaluating as (Not x) == y rather than not (x == y) I can say for sure that the precedence is as expected. I always use not ... == ... Instead of !=. -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 5/13/2013 1:26 PM, Fábio Santos wrote: On 13 May 2013 11:04, Alister alister.w...@ntlworld.com mailto:alister.w...@ntlworld.com wrote: this looks to me like an issue with operator precidence you code is evaluating as (Not x) == y rather than not (x == y) I can say for sure that the precedence is as expected. I always use not ... == ... Instead of !=. If you don't mind my asking, why do you do that? --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Tue, May 14, 2013 at 4:08 AM, Ned Batchelder n...@nedbatchelder.com wrote: On 5/13/2013 1:26 PM, Fábio Santos wrote: On 13 May 2013 11:04, Alister alister.w...@ntlworld.com wrote: this looks to me like an issue with operator precidence you code is evaluating as (Not x) == y rather than not (x == y) I can say for sure that the precedence is as expected. I always use not ... == ... Instead of !=. If you don't mind my asking, why do you do that? I think it's fairly obvious. Like the stumpy-tailed dog from The Loaded Dog [1], he's saving up the != operator in case he needs it later. ChrisA [1] Full text here. http://jendi.bowmeow.com.au/loadeddog1.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
I think it is more readable. When doing more complicated statements I use != instead, but when it's a single test I prefer not … == It's a personal thing. It may also have to do with the fact that I didn't know python had != when I was a novice. On 13 May 2013 19:08, Ned Batchelder n...@nedbatchelder.com wrote: On 5/13/2013 1:26 PM, Fábio Santos wrote: On 13 May 2013 11:04, Alister alister.w...@ntlworld.com wrote: this looks to me like an issue with operator precidence you code is evaluating as (Not x) == y rather than not (x == y) I can say for sure that the precedence is as expected. I always use not ... == ... Instead of !=. If you don't mind my asking, why do you do that? --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Mon, 13 May 2013 19:28:29 +0100, Fábio Santos wrote: I think it is more readable. When doing more complicated statements I use != instead, but when it's a single test I prefer not … == It's a personal thing. It may also have to do with the fact that I didn't know python had != when I was a novice. On 13 May 2013 19:08, Ned Batchelder n...@nedbatchelder.com wrote: I would then still write it as not (x == y) to make it clear to myself avoid any possible confusion although I think that X != Y is much cleaner. 2 lines from the zen stand out here:- Explicit is better than implicit. in the face of ambiguity refuse the temptation to guess. there are many features of Python ( other languages) i did not now when I started but have adopted once I understood what they were how they worked. then again use what you are most comfortable with. Practicality beats purity -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Mon, May 13, 2013 at 10:17 PM, Alister alister.w...@ntlworld.com wrote: On Mon, 13 May 2013 19:28:29 +0100, Fábio Santos wrote: I think it is more readable. When doing more complicated statements I use != instead, but when it's a single test I prefer not … == It's a personal thing. It may also have to do with the fact that I didn't know python had != when I was a novice. On 13 May 2013 19:08, Ned Batchelder n...@nedbatchelder.com wrote: I would then still write it as not (x == y) to make it clear to myself avoid any possible confusion although I think that X != Y is much cleaner. 2 lines from the zen stand out here:- Explicit is better than implicit. in the face of ambiguity refuse the temptation to guess. And here I was, thinking I was being pythonic. I hope other people using my code will be able to understand it well, not just myself, so using the most common idioms should be the best way to go. -- Fábio Santos -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 13/05/2013 22:17, Alister wrote: On Mon, 13 May 2013 19:28:29 +0100, Fábio Santos wrote: I think it is more readable. When doing more complicated statements I use != instead, but when it's a single test I prefer not … == It's a personal thing. It may also have to do with the fact that I didn't know python had != when I was a novice. On 13 May 2013 19:08, Ned Batchelder n...@nedbatchelder.com wrote: I would then still write it as not (x == y) to make it clear to myself avoid any possible confusion although I think that X != Y is much cleaner. 2 lines from the zen stand out here:- Explicit is better than implicit. in the face of ambiguity refuse the temptation to guess. there are many features of Python ( other languages) i did not now when I started but have adopted once I understood what they were how they worked. then again use what you are most comfortable with. Practicality beats purity I much prefer the alternative for != but some silly people insisted that this be removed from Python3. Just how stupid can you get? -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 05/13/2013 06:53 PM, Mark Lawrence wrote: On 13/05/2013 22:17, Alister wrote: On Mon, 13 May 2013 19:28:29 +0100, Fábio Santos wrote: I think it is more readable. When doing more complicated statements I use != instead, but when it's a single test I prefer not … == It's a personal thing. It may also have to do with the fact that I didn't know python had != when I was a novice. On 13 May 2013 19:08, Ned Batchelder n...@nedbatchelder.com wrote: I would then still write it as not (x == y) to make it clear to myself avoid any possible confusion although I think that X != Y is much cleaner. 2 lines from the zen stand out here:- Explicit is better than implicit. in the face of ambiguity refuse the temptation to guess. there are many features of Python ( other languages) i did not now when I started but have adopted once I understood what they were how they worked. then again use what you are most comfortable with. Practicality beats purity I much prefer the alternative for != but some silly people insisted that this be removed from Python3. Just how stupid can you get? So which special methods should the operator call? By rights it ought to call both __gt__ and __lt__ and return True if either of them is True. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 2013.05.13 17:53, Mark Lawrence wrote: I much prefer the alternative for != but some silly people insisted that this be removed from Python3. It's not removed from Python 3, though: Python 3.3.1 (v3.3.1:d9893d13c628, Apr 6 2013, 20:30:21) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. from __future__ import barry_as_FLUFL 3 2 True -- CPython 3.3.1 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 13May2013 19:22, Dave Angel da...@davea.name wrote: | On 05/13/2013 06:53 PM, Mark Lawrence wrote: | I much prefer the alternative for != but some silly people insisted | that this be removed from Python3. Just how stupid can you get? | | So which special methods should the operator call? By rights it | ought to call both __gt__ and __lt__ and return True if either of | them is True. Surely it should require both of them to be true... Personally I'm for != given we have ==. Aside from notational consistency it makes conceptual sense for unordered types, which does not really. Cheers, -- Cameron Simpson c...@zip.com.au -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Mon, May 13, 2013 at 5:27 PM, Andrew Berg bahamutzero8...@gmail.com wrote: On 2013.05.13 17:53, Mark Lawrence wrote: I much prefer the alternative for != but some silly people insisted that this be removed from Python3. It's not removed from Python 3, though: Python 3.3.1 (v3.3.1:d9893d13c628, Apr 6 2013, 20:30:21) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. from __future__ import barry_as_FLUFL 3 2 True I'd like to see ≠ added as a synonym for !=, even if nobody uses it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 05/13/2013 07:30 PM, Cameron Simpson wrote: On 13May2013 19:22, Dave Angel da...@davea.name wrote: | On 05/13/2013 06:53 PM, Mark Lawrence wrote: | I much prefer the alternative for != but some silly people insisted | that this be removed from Python3. Just how stupid can you get? | | So which special methods should the operator call? By rights it | ought to call both __gt__ and __lt__ and return True if either of | them is True. Surely it should require both of them to be true... Then it would never be true. At least not for numbers. Personally I'm for != given we have ==. Aside from notational consistency it makes conceptual sense for unordered types, which does not really. That's the point of mentioning __gt__ and __lt__, they aren't available on unordered types. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 13May2013 21:41, Dave Angel da...@davea.name wrote: | On 05/13/2013 07:30 PM, Cameron Simpson wrote: | On 13May2013 19:22, Dave Angel da...@davea.name wrote: | | On 05/13/2013 06:53 PM, Mark Lawrence wrote: | | I much prefer the alternative for != but some silly people insisted | | that this be removed from Python3. Just how stupid can you get? | | | | So which special methods should the operator call? By rights it | | ought to call both __gt__ and __lt__ and return True if either of | | them is True. | | Surely it should require both of them to be true... | | Then it would never be true. At least not for numbers. Well that was the point. The _symbol_ looks like it should want both. Next time I'll include the smiley. Cheers, -- Cameron Simpson c...@zip.com.au I really don't like :-) symbols as well. I feel that if you can't see the pie coming, you deserve whipped cream up your nose. - r...@cherry.cray.com (rob derrick) -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Mon, 13 May 2013 19:22:24 -0400, Dave Angel wrote: So which special methods should the operator call? By rights it ought to call both __gt__ and __lt__ and return True if either of them is True. The operator comes from Pascal, where it was used as not equal since ASCII doesn't include the ≠ operator. Algol 60, by contrast, used ≠ since it was invented before ASCII. The use of ! as not is a C-ism and isn't universal. Given the data types Pascal had as standard back when it was invented, I think it is fair to say that less than, or greater than was logically equivalent to not equal to. That's no longer the case though. Interestingly, later versions of Apple's Standard Apple Numeric Environment (SANE) included separate relational operations for less than or greater than and not equal to. So if x was a NAN, then you could have pseudo-code like this: x != y # true x y # false -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Mon, 13 May 2013 21:17:41 +, Alister wrote: I would then still write it as not (x == y) to make it clear to myself avoid any possible confusion although I think that X != Y is much cleaner. I think that is sad. If I read not (x == y) I would assume that the person writing the code didn't understand Python syntax or know its standard operators. The exception is if x or y was some unusual type where the __ne__ method does something different to the logical reverse of the __eq__ method. But if that is the case, I would expect a comment warning about it. If x and y were standard objects like floats, strings, etc. then writing out not (x == y) in full is as sensible as writing out these in full: x + -y # instead of x - y alist.insert(len(alist), 99) # instead of alist.append(99) # instead of adict.clear() for key in list(adict.keys()): del adict[key] x+x+x+x+x+x # instead of x*6 I'm sure any experienced Python programmer can come up with a hypothetical scenario where you would need to write things out the long way, but that doesn't mean that we should do so all the time. 2 lines from the zen stand out here:- Explicit is better than implicit. in the face of ambiguity refuse the temptation to guess. != is explicit. There is no ambiguity that needs to be guessed. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 5/12/2013 7:23 PM, Mr. Joe wrote:
I seem to stumble upon a situation where != operator misbehaves in
python2.x. Not sure if it's my misunderstanding or a bug in python
implementation. Here's a demo code to reproduce the behavior -
# -*- coding: utf-8 -*-
from __future__ import unicode_literals, print_function
class DemoClass(object):
def __init__(self, val):
self.val = val
def __eq__(self, other):
return self.val == other.val
x = DemoClass('a')
y = DemoClass('a')
print(x == y: {0}.format(x == y))
print(x != y: {0}.format(x != y))
print(not x == y: {0}.format(not x == y))
In python3, the output is as expected:
x == y: True
x != y: False
not x == y: False
In Python 3, if __ne__ isn't defined, != will call __eq__ and negate
the result.
In python2.7.3, the output is:
x == y: True
x != y: True
not x == y: False
Which is not correct!!
In Python 2, != only calls __ne__. Since you don't have one defined,
it's using the built-in object comparison, and since x and y are
different objects, they are not equal to each other, so x != y is True.
Thanks in advance for clarifications.
Regards,
TB
--
http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
Am 13.05.2013 01:23, schrieb Mr. Joe: I seem to stumble upon a situation where != operator misbehaves in python2.x. Not sure if it's my misunderstanding or a bug in python implementation. Here's a demo code to reproduce the behavior - Python 2.7 doesn't use the negation of __eq__ when your class doesn't provide a __ne__ function. Just add a print() to your __eq__ method and you'll notice the different. You have to provide both: class DemoClass(object): def __init__(self, val): self.val = val def __eq__(self, other): if not isinstance(other, DemoClass): return NotImplemented return self.val == other.val def __ne__(self, other): if not isinstance(other, DemoClass): return NotImplemented return self.val != other.val or def __ne__(self, other): result = self.__eq__(other) if result is NotImplemented: return NotImplemented return not result -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On Sun, May 12, 2013 at 5:23 PM, Mr. Joe titani...@gmail.com wrote: I seem to stumble upon a situation where != operator misbehaves in python2.x. Not sure if it's my misunderstanding or a bug in python implementation. Here's a demo code to reproduce the behavior - The != operator is implemented by the __ne__ special method. In Python 3, the default implementation of __ne__ is to call __eq__ and return the opposite of whatever it returns. In Python 2, __ne__ calls the older __cmp__ method instead, which is no longer meaningful in Python 3. -- http://mail.python.org/mailman/listinfo/python-list
Re: Differences of != operator behavior in python3 and python2 [ bug? ]
On 13/05/2013 00:40, Ian Kelly wrote:
On Sun, May 12, 2013 at 5:23 PM, Mr. Joe titani...@gmail.com wrote:
I seem to stumble upon a situation where != operator misbehaves in
python2.x. Not sure if it's my misunderstanding or a bug in python
implementation. Here's a demo code to reproduce the behavior -
The != operator is implemented by the __ne__ special method. In
Python 3, the default implementation of __ne__ is to call __eq__ and
return the opposite of whatever it returns.
One should be aware, however, that this doesn't necessarily apply to
classes inheriting from builtins other than object (a fact that recently
bit me on the a***):
class spam:
def __eq__(self, other):
print('spam')
return super().__eq__(other)
class eggs(list):
def __eq__(self, other):
print('eggs')
return super().__eq__(other)
spam() != spam()
spam
spam
True
eggs() != eggs()
False
--
http://mail.python.org/mailman/listinfo/python-list
