On Mon, Jan 1, 2018 at 8:50 PM, Ethan Smith <[email protected]> wrote:
> > > On Mon, Jan 1, 2018 at 5:03 PM, Chris Barker <[email protected]> > wrote: > >> On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull < >> [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]> wrote: > On Mon, Jan 1, 2018 at 7:50 PM, Ethan Smith <[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) -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
