Home Original page

[Python-Dev] PEP 557: Data Classes

Guido van Rossum guido at python.org
Sun Sep 10 14:49:52 EDT 2017 
On Sun, Sep 10, 2017 at 9:36 AM, Eric V. Smith <eric at trueblade.com> wrote:

> On 9/10/2017 10:00 AM, Michel Desmoulin wrote:
>
>> - any chance it becomes a built in later ? When classes have been
>> improved in Python 2, the object built-in was added. Imagine if we had
>> had to import it every time... Or maybe just plug it to object like
>> @object.dataclass.
>>
>
> Because of the choice of using module-level functions so as to not
> introduce conflicts in the object's namespace, it would be difficult to
> make this a builtin.
>

The temptation to make everything a builtin should be resisted.


> Although now that I think about it, maybe what are currently module-level
> functions should instead be methods on the "dataclass" decorator itself:
>
> @dataclass
> class C:
>   i: int = dataclass.field(default=1, init=False)
>   j: str
>
> c = C('hello')
>
> dataclass.asdict(c)
> {'i': 1, 'j': 'hello'}
>
> Then, "dataclass" would be the only name the module exports, making it
> easier to someday be a builtin. I'm not sure it's important enough for this
> to be a builtin, but this would make it easier. Thoughts? I'm usually not a
> fan of having attributes on a function: it's why
> itertools.chain.from_iterable() is hard to find.
>

Let's not do that.

It would be better to design the module so that people can write `from
dataclasses import *` and they will only get things that are clearly part
of dataclasses (I guess dataclass, field, asdict, and a few more like
that). That way people who really want this to look like a builtin can just
violate PEP 8.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170910/eeaa3963/attachment.html>
More information about the Python-Dev mailing list