Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171128/86c076a3/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 28, 2017 at 12:56 PM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/28/2017 1:57 PM, Guido van Rossum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would also be happy with a retreat, where we define `__eq__` to insist that the classes are the same, and people can override this to their hearts' content.<br>
</blockquote>
<br></span>
I agree. And I guess we could always add it later, if there's a huge demand and someone writes a decent implementation. There would be a slight backwards incompatibility, though. Frankly, I think it would never be needed.<br>
<br>
One question remains: do we do what attrs does: for `__eq__` and `__ne__` use an exact type match, and for the 4 ordered comparison operators use an isinstance check? On the comparison operators, they also ignore attributes defined on any derived class [0]. As I said, I couldn't find an attrs issue that discusses their choice. I'll ask Hynek over on the dataclasses github issue.<br>
<br>
Currently the dataclasses code on master uses an exact type match for all 6 methods.<br>
<br>
Eric.<br>
<br>
[0] That is, they do the following (using dataclasses terms):<br>
<br>
Given:<span class=""><br>
<br>
@dataclass<br>
class B:<br>
  i: int<br></span>
  j: int<br>
<br>
@dataclass<br>
class C:<br>
  k: int<br>
<br>
Then B.__eq__ is:<br>
<br>
def __eq__(self, other):<br>
  if other.__class__ is self.__class__:<br>
    return (other.i, other.j) == (self.i, self.j)<br>
  return NotImplemented<br>
<br>
And B.__lt__ is:<br>
<br>
def __lt__(self, other):<br>
  if isinstance(other, self.__class__):<br>
    return (other.i, other.j) < (self.i, self.j)<br>
  return NotImplemented<br>
<br>
So if you do:<br>
b = B(1, 2)<br>
c = C(1, 2, 3)<br>
<br>
Then `B(1, 2) < C(1, 2, 3)` ignores `c.k`.<br>
</blockquote></div><br></div><div class="gmail_extra">Hm. Maybe for the ordering comparisons we could defer to the class with the longest list of fields, as long as there's a subtype relationship? That way b<c and c>b would be equivalent, and both would use C.__gt__. Which had better not reject this on the basis that other is not an instance of a subclass of C.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">IIRC there's already something in the interpreter that tries the most derived class first for binary operators -- that may force our hand here.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4