On Mon, Jan 1, 2018 at 8:50 PM, Ethan Smith <et...@ethanhs.me> wrote:
> > > On Mon, Jan 1, 2018 at 5:03 PM, Chris Barker <chris.bar...@noaa.gov> > wrote: > >> On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull < >> turnbull.stephen...@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.bar...@noaa.gov> wrote: > On Mon, Jan 1, 2018 at 7:50 PM, Ethan Smith <et...@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)
_______________________________________________ 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
