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