[Python-Dev] PEP 557: Data Classes (original) (raw)

Guido van Rossum guido at python.org
Fri Sep 8 19:00:36 EDT 2017

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 <eric at 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(defaultfactory=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(defaulttypeisfactory=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 at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170908/194d8248/attachment.html>

More information about the Python-Dev mailing list