On Mon, Jan 1, 2018 at 5:03 PM, Chris Barker <chris.barker@noaa.gov> wrote:

On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull <turnbull.stephen.fw@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 interpretted Guido's proposal as being about all methods -- we _may_ want something special for __repr__, but I hope not.

But +1 for Guido's proposal, not only because it's easy to explain, but because it more naturally follows the usual inheritance logic:

The decorator's entire point is to auto-generate boilerplate code for you. Once it's done that it shouldn't, in the end, behave any differently than if you hand wrote that code. If you hand wrote the methods that the decorator creates for you, they would override any base class versions. So that's what it should do.

And the fact that you can optionally tell it not to in some particular case keeps full flexibility.

-CHB

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.

> I grant that there may be many reasons why one would be deriving
dataclasses from dataclasses

Will you get the "right" __repr__ now if you derive a datacalss 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__.

~>Ethan Smith

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA 98115   (206) 526-6317   main reception

Chris.Barker@noaa.gov

_______________________________________________
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/ethan%40ethanhs.me