On Sun, Sep 10, 2017 at 9:36 AM, Eric V. Smith <e...@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)
_______________________________________________
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
