On Mon, Jan 1, 2018 at 8:50 PM, Ethan Smith <ethan@ethanhs.me> wrote:

On Mon, Jan 1, 2018 at 5:03 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> 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 <chris.barker@noaa.gov> wrote:

On Mon, Jan 1, 2018 at 7:50 PM, Ethan Smith <ethan@ethanhs.me> 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)

--Guido van Rossum (python.org/~guido)