Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #45210 > unrolled thread

Differences of "!=" operator behavior in python3 and python2 [ bug? ]

Started by"Mr. Joe" <titanix88@gmail.com>
First post2013-05-13 05:23 +0600
Last post2013-05-14 17:31 +1000
Articles 19 — 11 participants

Back to article view | Back to comp.lang.python


Contents

  Differences of "!=" operator behavior in python3 and python2 [ bug? ] "Mr. Joe" <titanix88@gmail.com> - 2013-05-13 05:23 +0600
    Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Alister <alister.ware@ntlworld.com> - 2013-05-13 09:59 +0000
      Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Fábio Santos <fabiosantosart@gmail.com> - 2013-05-13 18:26 +0100
      Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Ned Batchelder <ned@nedbatchelder.com> - 2013-05-13 14:08 -0400
      Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Chris Angelico <rosuav@gmail.com> - 2013-05-14 04:15 +1000
      Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Fábio Santos <fabiosantosart@gmail.com> - 2013-05-13 19:28 +0100
        Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Alister <alister.ware@ntlworld.com> - 2013-05-13 21:17 +0000
          Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Fábio Santos <fabiosantosart@gmail.com> - 2013-05-13 22:48 +0100
          Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-05-13 23:53 +0100
          Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Dave Angel <davea@davea.name> - 2013-05-13 19:22 -0400
            Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-14 05:09 +0000
              Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-14 19:01 -0400
                Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-15 00:15 +0000
                  Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-14 22:20 -0400
          Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Andrew Berg <bahamutzero8825@gmail.com> - 2013-05-13 18:27 -0500
          Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-13 17:32 -0600
          Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-14 05:21 +0000
            Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Alister <alister.ware@ntlworld.com> - 2013-05-15 14:41 +0000
          Re: Differences of "!=" operator behavior in python3 and python2 [ bug? ] Chris Angelico <rosuav@gmail.com> - 2013-05-14 17:31 +1000

#45210 — Differences of "!=" operator behavior in python3 and python2 [ bug? ]

From"Mr. Joe" <titanix88@gmail.com>
Date2013-05-13 05:23 +0600
SubjectDifferences of "!=" operator behavior in python3 and python2 [ bug? ]
Message-ID<mailman.1603.1368401007.3114.python-list@python.org>
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

[toc] | [next] | [standalone]


#45234

FromAlister <alister.ware@ntlworld.com>
Date2013-05-13 09:59 +0000
Message-ID<HP2kt.66723$Tl3.12499@fx29.fr7>
In reply to#45210
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

[toc] | [prev] | [next] | [standalone]


#45252

FromFábio Santos <fabiosantosart@gmail.com>
Date2013-05-13 18:26 +0100
Message-ID<mailman.1634.1368466014.3114.python-list@python.org>
In reply to#45234

[Multipart message — attachments visible in raw view] — view raw

On 13 May 2013 11:04, "Alister" <alister.ware@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 !=.

[toc] | [prev] | [next] | [standalone]


#45256

FromNed Batchelder <ned@nedbatchelder.com>
Date2013-05-13 14:08 -0400
Message-ID<mailman.1638.1368468525.3114.python-list@python.org>
In reply to#45234

[Multipart message — attachments visible in raw view] — view raw

On 5/13/2013 1:26 PM, Fábio Santos wrote:
>
>
> On 13 May 2013 11:04, "Alister" <alister.ware@ntlworld.com 
> <mailto:alister.ware@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.

[toc] | [prev] | [next] | [standalone]


#45259

FromChris Angelico <rosuav@gmail.com>
Date2013-05-14 04:15 +1000
Message-ID<mailman.1640.1368468931.3114.python-list@python.org>
In reply to#45234
On Tue, May 14, 2013 at 4:08 AM, Ned Batchelder <ned@nedbatchelder.com> wrote:
>
> On 5/13/2013 1:26 PM, Fábio Santos wrote:
>
>
> On 13 May 2013 11:04, "Alister" <alister.ware@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

[toc] | [prev] | [next] | [standalone]


#45260

FromFábio Santos <fabiosantosart@gmail.com>
Date2013-05-13 19:28 +0100
Message-ID<mailman.1641.1368470096.3114.python-list@python.org>
In reply to#45234

[Multipart message — attachments visible in raw view] — view raw

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" <ned@nedbatchelder.com> wrote:

>
> On 5/13/2013 1:26 PM, Fábio Santos wrote:
>
>
> On 13 May 2013 11:04, "Alister" <alister.ware@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.
>
>

[toc] | [prev] | [next] | [standalone]


#45264

FromAlister <alister.ware@ntlworld.com>
Date2013-05-13 21:17 +0000
Message-ID<VLckt.68242$kO.37986@fx14.fr7>
In reply to#45260
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" <ned@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

[toc] | [prev] | [next] | [standalone]


#45265

FromFábio Santos <fabiosantosart@gmail.com>
Date2013-05-13 22:48 +0100
Message-ID<mailman.1643.1368481718.3114.python-list@python.org>
In reply to#45264
On Mon, May 13, 2013 at 10:17 PM, Alister <alister.ware@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" <ned@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

[toc] | [prev] | [next] | [standalone]


#45267

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2013-05-13 23:53 +0100
Message-ID<mailman.1645.1368485596.3114.python-list@python.org>
In reply to#45264
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" <ned@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

[toc] | [prev] | [next] | [standalone]


#45269

FromDave Angel <davea@davea.name>
Date2013-05-13 19:22 -0400
Message-ID<mailman.1647.1368487365.3114.python-list@python.org>
In reply to#45264
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" <ned@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

[toc] | [prev] | [next] | [standalone]


#45283

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2013-05-14 05:09 +0000
Message-ID<5191c71c$0$29978$c3e8da3$5496439d@news.astraweb.com>
In reply to#45269
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

[toc] | [prev] | [next] | [standalone]


#45315

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2013-05-14 19:01 -0400
Message-ID<mailman.1683.1368572505.3114.python-list@python.org>
In reply to#45283
On 14 May 2013 05:09:48 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> 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 

	I thought it came from BASIC...
http://en.wikipedia.org/wiki/Dartmouth_BASIC 
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]


#45316

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2013-05-15 00:15 +0000
Message-ID<5192d3b8$0$29978$c3e8da3$5496439d@news.astraweb.com>
In reply to#45315
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.python@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

[toc] | [prev] | [next] | [standalone]


#45319

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2013-05-14 22:20 -0400
Message-ID<mailman.1685.1368584425.3114.python-list@python.org>
In reply to#45316
On 15 May 2013 00:15:53 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> 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.python@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").

	Algol was the biggest influence on Pascal, to my understanding --
but by the days of Pascal I suspect ASCII was the prime character set --
so no (ASCII art to ensure it gets through) |---  or =/= characters (I
believe ALGOL 60 used =/= [as a single glyph] for "not equal").

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]


#45270

FromAndrew Berg <bahamutzero8825@gmail.com>
Date2013-05-13 18:27 -0500
Message-ID<mailman.1648.1368487665.3114.python-list@python.org>
In reply to#45264
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

[toc] | [prev] | [next] | [standalone]


#45273

FromIan Kelly <ian.g.kelly@gmail.com>
Date2013-05-13 17:32 -0600
Message-ID<mailman.1651.1368488004.3114.python-list@python.org>
In reply to#45264
On Mon, May 13, 2013 at 5:27 PM, Andrew Berg <bahamutzero8825@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.

[toc] | [prev] | [next] | [standalone]


#45284

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2013-05-14 05:21 +0000
Message-ID<5191c9eb$0$29978$c3e8da3$5496439d@news.astraweb.com>
In reply to#45264
On Mon, 13 May 2013 21:17:41 +0000, 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

[toc] | [prev] | [next] | [standalone]


#45350

FromAlister <alister.ware@ntlworld.com>
Date2013-05-15 14:41 +0000
Message-ID<V8Nkt.65070$lc7.8554@fx19.fr7>
In reply to#45284
 
> != 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

[toc] | [prev] | [next] | [standalone]


#45288

FromChris Angelico <rosuav@gmail.com>
Date2013-05-14 17:31 +1000
Message-ID<mailman.1662.1368516704.3114.python-list@python.org>
In reply to#45264
On Tue, May 14, 2013 at 9:22 AM, Dave Angel <davea@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. :-)

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web