Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder7.xlned.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.029 X-Spam-Evidence: '*H*': 0.94; '*S*': 0.00; 'reason,': 0.07; 'default.': 0.09; 'false,': 0.09; 'implements': 0.09; 'operand': 0.09; 'things,': 0.09; 'cc:addr:python-list': 0.11; '"i': 0.16; 'defer': 0.16; 'it;': 0.16; 'unequal,': 0.16; 'wrote:': 0.18; 'obviously': 0.18; 'normally': 0.19; 'result.': 0.19; 'not,': 0.20; 'seems': 0.21; 'aug': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; 'integer': 0.24; "shouldn't": 0.24; 'skip:l 30': 0.24; 'mon,': 0.24; 'cc:2**0': 0.24; '>': 0.26; 'second': 0.26; 'header:In-Reply- To:1': 0.27; 'chris': 0.29; 'am,': 0.29; 'said,': 0.30; 'message- id:@mail.gmail.com': 0.30; 'url:mailman': 0.30; '3.2': 0.31; '>>>>': 0.31; 'invoke': 0.31; "we're": 0.32; 'quite': 0.32; 'url:python': 0.33; "can't": 0.35; 'received:209.85': 0.35; 'knows': 0.35; 'equal': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'false': 0.36; 'object,': 0.36; 'returning': 0.36; 'done': 0.36; 'url:listinfo': 0.36; 'url:org': 0.36; 'behind': 0.37; 'received:209': 0.37; 'skip:& 10': 0.38; 'handle': 0.38; 'skip:[ 10': 0.38; 'pm,': 0.38; 'url:mail': 0.40; 'url:about': 0.61; 'first': 0.61; 'back': 0.62; 'skip:n 10': 0.64; 'more': 0.64; 'to:addr:gmail.com': 0.65; 'side': 0.67; 'determine': 0.67; 'skip:r 30': 0.69; 'url:me': 0.69; 'reasoning': 0.91; 'sorry.': 0.91; 'why?': 0.91; 'directly.': 0.95; '2013': 0.98 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MsHhCSqdGc8N4TViCrX01DtGJMt3hJ4uXAnncsS89qc=; b=E24tnEmGAUtGubG/plGF17pBPsG8+alKKyq0HDCkiRcXGSPJEnwgrZzzhrO/uMTrc8 5XGdujyKtYtoeHz3jDmfi7bH1+YM1oO/sq9sxr1gMaffEm8KbyABkoZznHCjTEZxUlXd Q/+40IQEWwHpFn5Ln5k6ONSyYXDiMeb8GLliQTicAcadgdScNREmq7TYvt1cGmvSaRMK vMHIfmXvLvaVW59HDveju7G8zI4bhi8sm6iEZQWVLu+vBZ6SGONqyfRW87hW5HWGZBT4 CDnspxCWFT2pYKHc9b5Xh8sRnSuOPp91d4clSd15kffpATURQI2d4Ch7rHnX/EguETKq sEfQ== X-Gm-Message-State: ALoCoQk6GRyKSkNG2I2iL8iAi/wqveZrZ1BEBeulxpHPXb5f31tp09N34+gxocpVfL84kKXaVEMb MIME-Version: 1.0 X-Received: by 10.60.101.130 with SMTP id fg2mr1707732oeb.85.1375867458193; Wed, 07 Aug 2013 02:24:18 -0700 (PDT) X-Originating-IP: [61.172.185.246] In-Reply-To: References: <51FED74E.6080003@markusrother.de> Date: Wed, 7 Aug 2013 17:24:18 +0800 Subject: Re: Bug? ( () == [] ) != ( ().__eq__([]) ) From: Shiyao Ma To: Chris Angelico Content-Type: multipart/alternative; boundary=089e0111de9c1a9a5504e3581be4 Cc: Python X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 108 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1375867466 news.xs4all.nl 15887 [2001:888:2000:d::a6]:44161 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:52125 --089e0111de9c1a9a5504e3581be4 Content-Type: text/plain; charset=ISO-8859-1 Sorry. I don't quite get it. As you said, it first tries, leftOperand.__eq__(rightOperand) then if it returns NotImplemented, it goes to invoke rightOperand.__eq__(leftOperand). But for any reason, [] == () returns false, why? On Mon, Aug 5, 2013 at 7:06 AM, Chris Angelico wrote: > On Sun, Aug 4, 2013 at 11:35 PM, Markus Rother > wrote: > > Hello, > > > > The following behaviour seen in 3.2 seems very strange to me: > > > > As expected: > >>>> () == [] > > False > > > > However: > >>>> ().__eq__([]) > > NotImplemented > >>>> [].__eq__(()) > > NotImplemented > > You don't normally want to be calling dunder methods directly. The > reasoning behind this behaviour goes back to a few things, including a > way to handle "1 == Foo()" where Foo is a custom type that implements > __eq__; obviously the integer 1 won't know whether it's equal to a Foo > instance or not, so it has to defer to the second operand to get a > result. This deferral is done by returning NotImplemented, which is an > object, and so is true by default. I don't see any particular reason > for it to be false, as you shouldn't normally be using it; it's more > like a "null" state, it means "I don't know if we're equal or not". If > neither side knows whether they're equal, then they're presumed to be > unequal, but you can't determine that from a single call to __eq__. > > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://about.me/introom --089e0111de9c1a9a5504e3581be4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry. I don't quite get it. As you said, it first tri= es, leftOperand.__eq__(rightOperand) then if it returns NotImplemented, it = goes to invoke rightOperand.__eq__(leftOperand). But for any reason, [] =3D= =3D () returns false, why?


On Mon, Aug 5= , 2013 at 7:06 AM, Chris Angelico <rosuav@gmail.com> wrote:
On Sun, Aug 4, 2013 at 11:35 PM, Markus Rother <python@markusrother.de> wrote: > Hello,
>
> The following behaviour seen in 3.2 seems very strange to me:
>
> As expected:
>>>> () =3D=3D []
> False
>
> However:
>>>> ().__eq__([])
> NotImplemented
>>>> [].__eq__(())
> NotImplemented

You don't normally want to be calling dunder methods directly. Th= e
reasoning behind this behaviour goes back to a few things, including a
way to handle "1 =3D=3D Foo()" where Foo is a custom type that im= plements
__eq__; obviously the integer 1 won't know whether it's equal to a = Foo
instance or not, so it has to defer to the second operand to get a
result. This deferral is done by returning NotImplemented, which is an
object, and so is true by default. I don't see any particular reason for it to be false, as you shouldn't normally be using it; it's mor= e
like a "null" state, it means "I don't know if we're= equal or not". If
neither side knows whether they're equal, then they're presumed to = be
unequal, but you can't determine that from a single call to __eq__.

ChrisA
--
http://mail.python.org/mailman/listinfo/python-list



--
--089e0111de9c1a9a5504e3581be4--