(original) (raw)
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 derivingdataclasses from dataclassesWill 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