On 11/28/17 7:02 AM, Nick Coghlan wrote:
On 28 November 2017 at 17:41, Eric V. Smith <e...@trueblade.com> wrote:
One thing this doesn't let you do is compare instances of two different
subclasses of a base type:
@dataclass
class B:
i: int
@dataclass
class C1(B): pass
@dataclass
class C2(B): pass
You can't compare C1(0) and C2(0), because neither one is an instance of the
other's type. The test to get this case to work would be expensive: find the
common ancestor, and then make sure no fields have been added since then.
And I haven't thought through multiple inheritance.
I suggest we don't try to support this case.
That gets you onto problematic ground as far as transitivity is
concerned, since you'd end up with the following:
Excellent point, thanks for raising it.
>>> b = B(0); c1 = C1(0); c2 = C2(0)
>>> c1 == b
True
>>> b == c2
True
>>> c1 == c2
False
However, I think you can fix this by injecting the first base in the
MRO that defines a data field as a "__field_layout__" class attribute,
and then have the comparison methods check for "other.__field_layout__
is self.__field_layout__", rather than checking the runtime class
directly.
So in the above example, you would have:
>>> B.__field_layout__ is B
True
>>> C1.__field_layout__ is B
True
>>> C2.__field_layout__ is B
True
It would then be up to the dataclass decorator to set
`__field_layout__` correctly, using the follow rules:
1. Use the just-defined class if the class defines any fields
2. Use the just-defined class if it inherits from multiple base
classes that define fields and don't already share an MRO
3. Use a base class if that's either the only base class that defines
fields, or if all other base classes that define fields are already in
the MRO of that base class
That seems like a lot of complication for a feature that will be rarely
used. I'll give it some thought, especially the MI logic.
I think what you're laying out is an optimization for "do the classes
have identical fields, inherited through a common base class or
classes", right?
Eric.
_______________________________________________
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
