I think it would be useful to write 1-2 sentences about the problem with inheritance -- in that case you pretty much have to use a metaclass, and the use of a metaclass makes life harder for people who want to use their own metaclass (since metaclasses don't combine without some manual intervention).
On Fri, Sep 8, 2017 at 3:40 PM, Eric V. Smith <e...@trueblade.com> wrote: > On 9/8/17 3:20 PM, Mike Miller wrote: > >> >> On 2017-09-08 07:57, Eric V. Smith wrote: >> >>> I've written a PEP for… >>> >> >> Apologies for the following list dumb questions and bikesheds: >> >> >> - 'Classes can be thought of as "mutable namedtuples with defaults".' >> >> - A C/C++ (struct)ure sounds like a simpler description that many more >> would understand. >> > > Yes, other people have pointed out that this might not be the best > "elevator pitch" example. I'm thinking about it. > > - dataclass name: >> >> - class, redundant >> - data, good but very common >> - struct, used? >> - Record? (best I could come up with) >> > > There was a bunch of discussions on this. We're delaying the name > bikeshedding for later (and maybe never). > > - Source needs blanks between functions, hard to read. >> > > It's supposed to be hard to read! You're just supposed to think "am I glad > I don't have to read or write that". But I'll look at it. > > - Are types required? >> > > Annotations are required, the typing module is not. > > Maybe an example or two with Any? >> > > I'd rather leave it like it is: typing is referenced only once, for > ClassVar. > > - Intro discounts inheritance and metaclasses as "potentially interfering", >> but unclear why that would be the case. >> Inheritance is easy to override, metaclasses not sure? >> > > I don't really want to get in to the history of why people don't like > inheritance, single and multi. Or how metaclass magic can make life > difficult. I just want to point out that Data Classes don't interfere at > all. > > - Perhaps mention ORMs/metaclass approach, as prior art: >> >> https://docs.djangoproject.com/en/dev/topics/db/models/ >> >> - Perhaps mention Kivy Properties, as prior art: >> >> https://kivy.org/docs/api-kivy.properties.html >> > > Those are all good. Thanks. > > - For mutable default values: >> >> @dataclass >> class C: >> x: list # = field(default_factory=list) >> >> Could it detect list as a mutable class "type" and set it as a factory >> automatically? >> >> The PEP/bug #3 mentions using copy, but that's not exactly what I'm >> asking >> above. >> > > The problem is: how do you know what's a mutable type? There's no general > way to know. The behavior in the PEP is just mean to stop the worst of it. > > I guess we could have an option that says: call the type to create a new, > empty instance. > > @dataclass > class C: > x: list = field(default_type_is_factory=True) > > > Thanks for the critical reading and your comments. I'm going to push a new > version early next week, when I get back from traveling. > > Eric. > > > _______________________________________________ > 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/guido% > 40python.org > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ 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