<div dir="auto">But you always inherit __repr__, from object. The base class might also itself be a dataclass. I think it should only skip when the decorated class itself defines __repr__.</div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 29, 2017 3:47 AM, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 29 Dec 2017 02:23:56 -0800<br>
Ethan Smith <<a href="mailto:ethan@ethanhs.me">ethan@ethanhs.me</a>> wrote:<br>
><br>
> In a few cases I want to override the repr of the AST nodes. I wrote a<br>
> __repr__ and ran the code but lo and behold I got a type error. I couldn't<br>
> override it. I quickly learned that one needs to pass a keyword to the<br>
> dataclass decorator to tell it *not* to auto generate methods you override.<br>
><br>
> I have two usability concerns with the current implementation. I emailed<br>
> Eric about the first, and he said I should ask for thoughts here. The<br>
> second I found after a couple of days sitting on this message.<br>
><br>
> The first is that needing both a keyword and method is duplicative and<br>
> unnecessary. Eric agreed it was a hassle, but felt it was justified<br>
> considering someone may accidentally override a dataclass method. I<br>
> disagree with this point of view as dataclasses are billed as providing<br>
> automatic methods. Overriding via method definition is very natural and<br>
> idiomatic.<br>
<br>
Agreed.  We shouldn't take magic too far just for the sake of<br>
protecting users against their own (alleged) mistakes.  And I'm not<br>
sure how you "accidentally" override a dataclass method (if I'm<br>
implementing a __repr__ I'm doing so deliberately :-)).<br>
<br>
> The second concern, which I came across more recently, is if I have a base<br>
> class, and dataclasses inherit from this base class, inherited __repr__ &<br>
> co are silently overridden by dataclass. This is both unexpected, and also<br>
> means I need to pass a repr=False to each subclass' decorator to get<br>
> correct behavior, which somewhat defeats the utility of subclassing. Im not<br>
> as sure a whole lot can be done about this though.<br>
<br>
Agreed as well.  If I make the effort of having a dataclass inherit<br>
from a base class, I probably don't want the base class' methods to be<br>
silently overriden by machine-generated methods.  Of course, that can<br>
be worked around by using multiple inheritance, you just need to be<br>
careful and add a small amount of class definition boilerplate.<br>
<br>
I would expect dataclass parameters such as `repr` to be tri-state:<br>
<br>
* repr=None (the default): only provide a machine-generated<br>
  implementation if none is already defined (either on a base class or<br>
  in the dataclass namespace... ignoring runtime-provided defaults such<br>
  as object.__repr__)<br>
* repr=False: never provide a machine-generated implementation<br>
* repr=True: always provide a machine-generated implementation, even<br>
  overriding a previous user-defined implementation<br>
<br>
Regards<br>
<br>
Antoine.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</blockquote></div></div>