Following up on this subthread (inline below). On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith <e...@trueblade.com> wrote:
> On 11/27/2017 1:04 AM, Nick Coghlan wrote: > >> On 27 November 2017 at 15:04, Greg Ewing <greg.ew...@canterbury.ac.nz> >> wrote: >> >>> Nick Coghlan wrote: >>> >>>> >>>> Perhaps the check could be: >>>> >>>> (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all >>>> (individual fields match) >>>> >>> >>> >>> I think the types should *always* have to match, or at least >>> one should be a subclass of the other. Consider: >>> >>> @dataclass >>> class Point3d: >>> x: float >>> y: float >>> z: float >>> >>> @dataclass >>> class Vector3d: >>> x: float >>> y: float >>> z: float >>> >>> Points and vectors are different things, and they should never >>> compare equal, even if they have the same field names and values. >>> >> >> And I guess if folks actually want more permissive structure-based >> matching, that's one of the features that collections.namedtuple >> offers that data classes don't. >> > > And in this case you could also do: > astuple(point) == astuple(vector) > Didn't we at one point have something like isinstance(other, self.__class__) and fields(other) == fields(self) and <all individual fields match> (plus some optimization if the types are identical)? That feels ideal, because it means you can subclass Point just to add some methods and it will stay comparable, but if you add fields it will always be unequal. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
