On Mon, Jan 1, 2018 at 8:50 PM, Ethan Smith <[email protected]
<mailto:[email protected]>> wrote:
On Mon, Jan 1, 2018 at 5:03 PM, Chris Barker <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull
<[email protected]
<mailto:[email protected]>> wrote:
Just use the simple rule that a new
__repr__ is generated unless provided in the dataclass.
are we only talking about __repr__ here ???
I interpreted Guido's proposal as being about all methods -- we
_may_ want something special for __repr__, but I hope not.
[...]
I interpreted this to be for all methods as well, which makes sense.
Special casing just __repr__ doesn't make sense to me, but I will
wait for Guido to clarify.
Indeed, I just wrote __repr__ for simplicity. This should apply to all
special methods. (Though there may be some complications for
__eq__/__ne__ and for the ordering operators.)
On Mon, Jan 1, 2018 at 9:44 PM, Chris Barker <[email protected]
<mailto:[email protected]>> wrote:
On Mon, Jan 1, 2018 at 7:50 PM, Ethan Smith <[email protected]
<mailto:[email protected]>> wrote:
Will you get the "right" __repr__ now if you derive a
dataclass from a dataclass? That would be a nice feature.
The __repr__ will be generated by the child dataclass unless the
user overrides it. So I believe this is the "right" __repr__.
what I was wondering is if the child will know about all the fields
in the parent -- so it could make a full __repr__.
Yes, there's a class variable (__dataclass_fields__) that identifies the
parent fields. The PEP doesn't mention this or the fact that special
methods (like __repr__ and __init__) can tell whether a base class is a
dataclass. It probably should though. (@Eric)