[Python-Dev] Concerns about method overriding and subclassing with dataclasses

Ethan Smith ethan at ethanhs.me
Fri Dec 29 05:23:56 EST 2017

Hello all,

I've recently been experimenting with dataclasses. They totally rock! A lot
of the boilerplate for the AST I've designed in Python is automatically
taken care of, it's really great! However, I have a few concerns about the

In a few cases I want to override the repr of the AST nodes. I wrote a
__repr__ and ran the code but lo and behold I got a type error. I couldn't
override it. I quickly learned that one needs to pass a keyword to the
dataclass decorator to tell it *not* to auto generate methods you override.

I have two usability concerns with the current implementation. I emailed
Eric about the first, and he said I should ask for thoughts here. The
second I found after a couple of days sitting on this message.

The first is that needing both a keyword and method is duplicative and
unnecessary. Eric agreed it was a hassle, but felt it was justified
considering someone may accidentally override a dataclass method. I
disagree with this point of view as dataclasses are billed as providing
automatic methods. Overriding via method definition is very natural and
idiomatic. I don't really see how someone could accidentally override a
dataclass method if methods were not generated by the dataclass decorator
that are already defined in the class at definition time.

The second concern, which I came across more recently, is if I have a base
class, and dataclasses inherit from this base class, inherited __repr__ &
co are silently overridden by dataclass. This is both unexpected, and also
means I need to pass a repr=False to each subclass' decorator to get
correct behavior, which somewhat defeats the utility of subclassing. Im not
as sure a whole lot can be done about this though.

I appreciate any thoughts folks have related to this.

~>Ethan Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171229/d27a47f1/attachment.html>

More information about the Python-Dev mailing list