This is an implementation of PEP 557, Data Classes.

Guido and I discussed this yesterday, and we decided we'd just copy.copy() the default values when creating a new instance.

The __init__ code I'm currently generating for:

@dataclass
class C:
    x: list = []

Looks something like:

def __init__(self, x=[]):
    self.x = copy.copy(x)

But I don't think this is what we really want. I don't think we want to call copy.copy() if passed in an unrelated list, like C(x=mylist). Maybe __init__ should check and only call copy.copy() if x is C.x?

So:

def __init__(self, x=C.x):
    self.x = copy.copy(x) if x is C.x else x

?

(I haven't checked that this actually works as written, but the idea is to only copy the argument if it's the same object as the default that was assigned in the class creation statement.)

This PR adds two keyword arguments copy_fields and nested to asdict() and astuple(). I think the first one should be on by default, so that simple mutable fields (like lists) will be copied by asdict() and astuple().

As well, as discussed in https://github.com/ericvsmith/dataclasses/pull/26, this adds dict_factory keyword argument, so that a user can use OrderedDict or other custom mapping.

Currently the post-init function __dataclass_post_init__ takes no parameters. Should it be possible to pass one or more parameters from __init__ to the post-init function? Is it possible to make the parameter optional?

It would be nice to pass parameters to __init__ which do not initialize fields, but are accessible to the post-init function. But, it might mess up the interface too much, and there are issues with calling __dataclass_post_init__'s super() function if we decide to change the number of parameters.

This issue is a placeholder to decide this issue before the code and PEP are finalized. Any suggestions or thoughts are welcome.

As I’ve already mentioned by e-mail, I’m strongly opposed to call this concept “data classes”.

Having an easy way to define many small class with attributes is nothing about data, it’s about good OO design.

Calling it “data classes” implies that they differ from…“code classes” I guess?

One of the things people love about attrs is that it’s helping them to write regular classes which they can add methods to without any subclassing or other magic. IOW: to focus on the actual code they want to write as opposed to generic boilerplate.

Debasing them by name seems like a poor start to me. We do have data containers in the stdlib (namedtuples, SimpleNamespace) so I don’t see a reason to add a third to the family – even if just by name.

I don't mean this as a dig at the project here, but a serious question:

Is there any reason this project should exist?

Every aspect of the design here appears to be converging further in the direction of exact duplication of functionality available within attrs, except those which are features already on attrs's roadmap. The attrs maintainers have carefully considered a number of subtle issues related to this problem domain, and every discussion I have observed thus far on the dataclasses repo has paralleled the reasoning process that went into attrs's original design or its maintenance. (Remembering, also, that attrs is itself a second-generation project and there was a lot of learning that came from characteristic.)

I haven't had time to read all of the python-ideas thread, but all of the objections to attrs that I could find seem to have to do with whimsical naming or a desire to shoehorn convenient class creation into a "special" role that is just for "data" and not for regular classes somehow. I shouldn't be passive-aggressive here, so I should just say: I can't follow Nick's reasoning on #1 at all :-).

The silly names could be modified by a trivially tiny fork, if that is really a deal-breaker for stdlib adoption; honestly I find that the names grow on you. (More than one attrs user has separately come up with the idea that it is a lot like Python's significant whitespace.)

That said, of course there may be some reasons or some broader goal that I'm missing, but if this is the case it seems like writing a very clear "goals / non-goals / rejected approaches" section for the PEP itself would be worthwhile. The reasons given in the PEP don't really make sense; the need to support python 2 hasn't been a drag on python 3 that I'm aware of, and annotation-based attribute definition is coming to attrs itself; it's a relatively small extension.

Versions

• Python 3.6.5

• mypy==0.620+dev.bc0b551d8df2baadc44f0c3b0b801fcc12119658

• dataclasses==0.6

What's wrong

$ cat f2.py 
from dataclasses import dataclass
print('works!')
$ python f2.py 
works!
$ mypy f2.py 
f2.py:1: error: Cannot find module named 'dataclasses'
f2.py:1: note: (Perhaps setting MYPYPATH or using the "--ignore-missing-imports" flag would help)

So the natural way is to use MYPYPATH to point to the specific package, dataclasses in this case. The problem is dataclasses package is installed directly in site-packages (virtual_env_path/lib/python3.6/site-packages/dataclasses.py in my case), and it's an error (and a bad idea) to pass the whole site-packages to MYPYPATH.

When I manually move the file from /site-packages/dataclasses.py to /site-packages/dataclasses/dataclasses.py and pass the path to MYPYPATH it's working as expected: no mypy error. Unfortunately, this is not the solution I can use.

I reported this issue on mypy page (https://github.com/python/mypy/issues/5342) and was told that:

The backport package can fix this by including stubs (presumably the same ones that are in typeshed) and marking itself as typed by using py.typed.

Can anything be done about it? I cannot migrate to Python 3.7 yet and would benefit much from mypy actually understanding dataclasses.

It would be helpful to have a list of functional differences between dataclasses and attrs, broken down by @dataclass vs @attr.s and field vs attr.ib.

This would be useful and illuminating for a few reasons:

It would make it easier to vet the logic behind, and need for, each of the proposed differences.

@hynek and @Tinche have invested years of thought into the current design: deviating from it without fully understanding the history and reasoning behind each decision might lead to this project needlessly repeating mistakes. I'm glad to see that the attrs devs have already been brought into several issues. My hope is we can get a bird's eye view so that nothing slips through the cracks.

If the differences aren't too great (and ideally they will not be, see above) I'd like to see a dataclass compatibility mode for attrs (e.g. from attrs import dataclass, field).

I'm glad that this badly-needed feature is being worked on, but sadly I'm stuck in python 2 for at least another 2 years, so it's important to me, and surely many attrs-users, to have an easy path to adoption once this becomes part of stdlib.

In #3, we discussed mutable defaults which included talk of factory functions. Having resolved #3, this issue is about how to specify default value factory functions.

Some options:

1. A new parameter to field(). For now, let's call it factory:

   @dataclass
    class Foo:
        x: list = field(factory=list, repr=False)

It would be an error to specify both default= and factory=.

2. Re-use the default parameter to field(), marking it as a factory function so we can determine whether to call it. For now, let's mark it by using Factory(callable).

    @dataclass
    class Foo:
        x: list = field(default=Factory(list), repr=False)

3. Have a separate flavor of field used with factory functions. For now, let's assume it's called factory_field. It would not have a default= parameter:

    @dataclass
    class Foo:
       x: list = factory_field(list, repr=False)

I don't have a real preference among these. I sense we should go with whatever makes mypy's life easier, but I don't know what that would be. I suspect it would be 3, since I think mypy could be told that the type of factory_field(callable) is the type of callable(). But I'm just hypothesizing, and am interested in the opinion of experts.

From a discussion with @raymondh:

Should we auto-generate some sort of doc string for __init__, or allow the user to specify one (maybe as a param to @dataclass)?

I'm not sure a generated one wouldn't have too much noise to be useful.

Since we decided in issue #8 to use module level helper functions instead of instance methods, I want to add the first such function.

dataclasses.fields(cls) will return a tuple of Field objects defined in cls. Each Field object represents one field in the class.

This will be the basic building block for a number of introspection methods.

attrs returns object that can be either indexed or accessed by field name. I think that's a good idea, but I'm not going to implement it at first.

Currently the draft PEP specifies and the code supports the optional ability to add __slots__. This is the one place where @dataclass cannot just modify the given class and return it: because __slots__ must be specified at class creation time, it's too late by the time the dataclass decorator gets control. The current approach is to dynamically generate a new class while setting __slots__ in the new class and copying over other class attributes. The decorator then returns the new class.

The question is: do we even want to support setting __slots__? Is having __slots__ important enough to have this deviation from the "we just add a few dunder methods to your class" behavior?

I see three options:

1. Leave it as-is, with @dataclass(slots=True) returning a new class.
2. Completely remove support for setting __slots__.
3. Add a different decorator, say @add_slots, which takes a data class and creates a new class with __slots__ set.

I think we should either go with 2 or 3. I don't mind not supporting __slots__, but if we do want to support it, I think it's easier to explain with a separate decorator.

@add_slots
@dataclass
class C:
    x: int
    y: int

It would be an error to use @add_slots on a non-dataclass class.

New in version 3.10. kw_only: If true (the default value is False), then all fields will be marked as keyword-only. If a field is marked as keyword-only, then the only effect is that the init() parameter generated from a keyword-only field must be specified with a keyword when init() is called. There is no effect on any other aspect of dataclasses. See the parameter glossary entry for details. Also see the KW_ONLY section.

Source: https://docs.python.org/3/library/dataclasses.html

It solves the limitation that a base class can't hold default values.

Example: https://stackoverflow.com/questions/51575931/class-inheritance-in-python-3-7-dataclasses

This is the same issue as https://bugs.python.org/issue36470, I open a new issue here for greater visibility.

Basically if one has a dataclass which defines an InitVars with a default value, and then uses dataclasses.replace on an instance without passing the init var as parameter to replace, a ValueError: InitVar '...' must be specified with replace() error is raised.

This is bad, because the InitVar already defines its default value, there's no need to expect a value when using replace(). It makes it impossible to use replace() at the same time as default InitVars.

The fix is trivial and there are already two PRs to upstream cpython dataclasses.

https://github.com/python/cpython/pull/17441 https://github.com/python/cpython/pull/20867

Although not part of the official API, I find add_slots to be quite useful. However, the combination with frozen dataclasses and pickling causes problems:

@add_slots
@dataclass(frozen=True)
class ExampleDataclass:
    foo: str
    bar: int



assert ExampleDataclass.__slots__ == ("foo", "bar")

assert pickle.loads(
    pickle.dumps(ExampleDataclass("a", 1))
) == ExampleDataclass("a", 1)

gives the following error:

dataclasses.FrozenInstanceError: cannot assign to field 'foo'

A quick fix would be to add something like this:

def _dataclass_getstate(self):
    return [getattr(self, f.name) for f in fields(self)]


def _dataclass_setstate(self, state):
    for field, value in zip(fields(self), state):
        # use setattr because dataclass may be frozen
        object.__setattr__(self, field.name, value)


def add_slots(cls):
    ...  # existing add_slots code here...
    # optionally only do these steps if the dataclass is frozen
    cls.__getstate__ = _dataclass_getstate
    cls.__setstate__ = _dataclass_setstate
    return cls

edit: typos

With the new py version restriction, pip will now as a result install dataclasses 0.6 if install is attempted on py37, since this is the last available version that satisfies this constraint. This might be a problem, since it shadows the builtin version. The reason this comes up is packaging a module the depends on dataclasses, but only python>=3.6, becomes tricky to do correctly. I believe the correct line is:

dataclasses>='0.7';python_version<'3.7'

Ideally, I think it would be nice if this dataclasses module simply returns the builtin python module if it's available (although I'm not sure how to implement that in practice!) If this isn't possible/desirable, perhaps you could add to the readme/docs something about how to install only on python<3.7 (e.g. using the above line)?

It seems the fix of https://bugs.python.org/issue34363 is missing in dataclasses version 0.7 backported to python 3.6

# 3.6.8 (default, Feb 28 2019, 22:12:13)
# [GCC 8.2.1 20181127](6, 0, 1)
# dataclasses 0.7

from dataclasses import InitVar, astuple, dataclass, field
from typing import NamedTuple, Tuple
import numpy as np

class A(NamedTuple):
    x: float = np.nan
    y: float = np.nan

@dataclass
class B:
    tuple_a: InitVar[Tuple] = None
    named_tuple_a: A = field(init=False, default=A())

    def __post_init__(self, tuple_a):
        if tuple_a is not None:
            self.named_tuple_a = A(*tuple_a)

b = B()
astuple(b)

>> (A(x=<generator object _astuple_inner.<locals>.<genexpr> at 0x7f7dec0902b0>, y=nan),)

While the same code in Python 3.7.4 gives:

# 3.7.4 (default, Oct  4 2019, 06:57:26)
# [GCC 9.2.0] (6, 0, 1)

from dataclasses import InitVar, astuple, dataclass, field
from typing import NamedTuple, Tuple
import numpy as np

class A(NamedTuple):
    x: float = np.nan
    y: float = np.nan

@dataclass
class B:
    tuple_a: InitVar[Tuple] = None
    named_tuple_a: A = field(init=False, default=A())

    def __post_init__(self, tuple_a):
        if tuple_a is not None:
            self.named_tuple_a = A(*tuple_a)

b = B()
astuple(b)

>> (A(x=nan, y=nan),)

https://bugs.python.org/issue35540 is the official bug report on the stdlib implementation in 3.7, copied below. There's a proposed fix at https://github.com/python/cpython/pull/11361 to special-case defaultdict.

_asdict_inner attempts to manually recursively deepcopy dicts by calling type(obj) with a generator of transformed keyvalue tuples @ https://github.com/python/cpython/blob/b2f642ccd2f65d2f3bf77bbaa103dd2bc2733734/Lib/dataclasses.py#L1080 . defaultdicts are dicts so this runs but unlike other dicts their first arg has to be a callable or None:

import collections
import dataclasses as dc

@dc.dataclass()
class C:
    d: dict

c = C(collections.defaultdict(lambda: 3, {}))
d = dc.asdict(c)

assert isinstance(d['d'], collections.defaultdict)
assert d['d']['a'] == 3

=>

Traceback (most recent call last):
  File "boom.py", line 9, in <module>
    d = dc.asdict(c)
  File "/Users/spinlock/.pyenv/versions/3.7.1/lib/python3.7/dataclasses.py", line 1019, in asdict
    return _asdict_inner(obj, dict_factory)
  File "/Users/spinlock/.pyenv/versions/3.7.1/lib/python3.7/dataclasses.py", line 1026, in _asdict_inner
    value = _asdict_inner(getattr(obj, f.name), dict_factory)
  File "/Users/spinlock/.pyenv/versions/3.7.1/lib/python3.7/dataclasses.py", line 1058, in _asdict_inner
    for k, v in obj.items())
TypeError: first argument must be callable or None

I understand that it isn't this bit of code's job to support every dict (and list etc.) subclass under the sun but given defaultdict is stdlib it's imo worth supporting explicitly.