On Mon, Jan 1, 2018 at 5:03 PM, Chris Barker <chris.bar...@noaa.gov> wrote:
> On Sat, Dec 30, 2017 at 7:27 AM, Stephen J. Turnbull < > turnbull.stephen...@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.bar...@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 > >
_______________________________________________ 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/archive%40mail-archive.com
