[Python-Dev] PEP 557: Data Classes

[Guido van Rossum]

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(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 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>