[Python-Dev] Second post: PEP 557, Data Classes (original) (raw)

Guido van Rossum guido at python.org
Mon Nov 27 10:51:58 EST 2017

Following up on this subthread (inline below).

On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith <eric at trueblade.com> wrote:

On 11/27/2017 1:04 AM, Nick Coghlan wrote:

On 27 November 2017 at 15:04, Greg Ewing <greg.ewing at 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

(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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171127/a663d04c/attachment.html>

More information about the Python-Dev mailing list