Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #51943
| References | <51FED74E.6080003@markusrother.de> |
|---|---|
| Date | 2013-08-05 00:06 +0100 |
| Subject | Re: Bug? ( () == [] ) != ( ().__eq__([]) ) |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.195.1375658082.1251.python-list@python.org> (permalink) |
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: >>>> () == [] > 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
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Bug? ( () == [] ) != ( ().__eq__([]) ) Chris Angelico <rosuav@gmail.com> - 2013-08-05 00:06 +0100
csiph-web