Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171127/379e73c4/attachment-0001.html below:
<div dir="auto">Sounds good. </div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 27, 2017 8:00 AM, "Eric V. Smith" <<a href="mailto:eric@trueblade.com">eric@trueblade.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/27/17 10:51 AM, Guido van Rossum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Following up on this subthread (inline below).<br>
<br>
On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith <<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a><br>
<mailto:<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>>> wrote:<br>
<br>
  On 11/27/2017 1:04 AM, Nick Coghlan wrote:<br>
<br>
    On 27 November 2017 at 15:04, Greg Ewing<br>
    <<a href="mailto:greg.ewing@canterbury.ac.nz" target="_blank">greg.ewing@canterbury.ac.nz</a><br>
    <mailto:<a href="mailto:greg.ewing@canterbury.ac.nz" target="_blank">greg.ewing@canterbury.<wbr>ac.nz</a>>> wrote:<br>
<br>
      Nick Coghlan wrote:<br>
<br>
<br>
        Perhaps the check could be:<br>
<br>
          (type(lhs) == type(rhs) or fields(lhs) ==<br>
        fields(rhs)) and all<br>
        (individual fields match)<br>
<br>
<br>
<br>
      I think the types should *always* have to match, or at least<br>
      one should be a subclass of the other. Consider:<br>
<br>
      @dataclass<br>
      class Point3d:<br>
         x: float<br>
         y: float<br>
         z: float<br>
<br>
      @dataclass<br>
      class Vector3d:<br>
         x: float<br>
         y: float<br>
         z: float<br>
<br>
      Points and vectors are different things, and they should never<br>
      compare equal, even if they have the same field names and<br>
      values.<br>
<br>
<br>
    And I guess if folks actually want more permissive structure-based<br>
    matching, that's one of the features that collections.namedtuple<br>
    offers that data classes don't.<br>
<br>
<br>
  And in this case you could also do:<br>
  astuple(point) == astuple(vector)<br>
<br>
<br>
Didn't we at one point have something like<br>
<br>
isinstance(other, self.__class__) and fields(other) == fields(self) and<br>
<all individual fields match><br>
<br>
(plus some optimization if the types are identical)?<br>
<br>
That feels ideal, because it means you can subclass Point just to add<br>
some methods and it will stay comparable, but if you add fields it will<br>
always be unequal.<br>
</blockquote>
<br>
I don't think we had that before, but it sounds right to me. I think it could be:<br>
<br>
isinstance(other, self.__class__) and len(fields(other)) == len(fields(self)) and <all individual fields match><br>
<br>
Since by definition if you're a subclass you'll start with all of the same fields. So if the len's match, you won't have added any new fields. That should be sufficiently cheap.<br>
<br>
Then the optimized version would be:<br>
<br>
(self.__class__ is other.__class__) or (isinstance(other, self.__class__) and len(fields(other)) == len(fields(self))) and <all individual fields match><br>
<br>
I'd probably further optimize len(fields(obj)), but that's the general idea.<br>
<br>
Eric.<br>
</blockquote></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