[Python-Dev] Concerns about method overriding and subclassing with dataclasses (original) (raw)

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 implementation.

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.

Cheers, ~>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