Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differences between BaseModel and @dataclass not expected based on documentation #710

SethMMorton opened this issue Aug 3, 2019 · 6 comments


Copy link

@SethMMorton SethMMorton commented Aug 3, 2019

Documentation Update Request

For bugs/questions:

  • OS: Linux
  • Python version: 3.7.3 | packaged by conda-forge
  • Pydantic version: 0.31.0

I liked the idea of using a dataclass instead of subclassing from BaseModel, so I tried changing the very first example from the docs to use dataclass instead of BaseModel and it fails.

from datetime import datetime
from typing import List
# from pydantic import BaseModel
from pydantic.dataclasses import dataclass

# class User(BaseModel):
class User:
    id: int
    name = 'John Doe'
    signup_ts: datetime = None
    friends: List[int] = []

external_data = {'id': '123', 'signup_ts': '2017-06-01 12:22', 'friends': [1, '2', b'3']}
user = User(**external_data)
# > User id=123 name='John Doe' signup_ts=datetime.datetime(2017, 6, 1, 12, 22) friends=[1, 2, 3]
# > 123


Traceback (most recent call last):
  File "", line 7, in <module>
  File "pydantic/", line 128, in pydantic.dataclasses.dataclass
    # +-------+-------+-------+--------+--------+
  File "pydantic/", line 123, in pydantic.dataclasses.dataclass.wrap
    #    |       |       |
  File "pydantic/", line 77, in pydantic.dataclasses._process_class
    #    +--- frozen= parameter
  File "/path/to/python/lib/python3.7/", line 834, in _process_class
    for name, type in cls_annotations.items()]
  File "/path/to/python/lib/python3.7/", line 834, in <listcomp>
    for name, type in cls_annotations.items()]
  File "/path/to/python/lib/python3.7/", line 727, in _get_field
    raise ValueError(f'mutable default {type(f.default)} for field '
ValueError: mutable default <class 'list'> for field friends is not allowed: use default_factory

I realize that this error is coming from the Std. Lib. dataclasses module, not pydantic. However, based on the language in the dataclasses section of the documentation I had expected what anything I could do with BaseModel I could do with dataclass as well.

If you don’t want to use pydantic’s BaseModel you can instead get the same data validation on standard dataclasses (introduced in python 3.7).

You can use all the standard pydantic field types and the resulting dataclass will be identical to the one created by the standard library dataclass decorator.

Can I suggest that there be a note or warning to the user that there are certain restrictions associated with using a dataclass that are not present when using BaseModel (such as not being able to use mutable defaults, as well as #484 and #639)?

Copy link

@samuelcolvin samuelcolvin commented Aug 5, 2019

happy to accept a PR to improve the documentation.

Copy link

@peteboothroyd peteboothroyd commented Aug 7, 2019

hi @samuelcolvin, first just want to say thanks for such a nice tool! So the reason I believe the mutable fields are not allowed on regular data classes is due to them being shared (probably unexpectedly for most people) similar to how if you do this:

class Y(object):
    def __init__(self,mutable=[]):
        self._mutable = mutable

y1 = Y()              # y1._mutable = []
y2 = Y()              # y2._mutable = []
y1._mutable.append(1) # y1._mutable = [1], but surprise! y2._mutable = [1]

The Pydantic BaseModel does not seem to suffer from this:

class X(pydantic.BaseModel):
    list_: List[int] = []

x1 = X()           # x1.list_ = []
x2 = X()           # x2.list_ = []
x1.list_.append(1) # x1.list_ = [1], x2.list_ = []

Have I understood that correctly? (Sorry if it's in the docs, I looked but couldn't find it specifically mentioned)

Copy link

@leiserfg leiserfg commented Sep 11, 2019

Copy link

@SethMMorton SethMMorton commented Sep 11, 2019

@leiserfg Yes, I tried to make that point very clear in the original issue with the text

I realize that this error is coming from the Std. Lib. dataclasses module, not pydantic.

The point of this issue is that the documentation makes it seem like you can get the same behavior inheriting from BaseModel as with using dataclass, but in corner cases like this that is not possible, and it should be documented as such. I do NOT think any pydantic behavior should be changed WRT to this issue.

Copy link

@leiserfg leiserfg commented Sep 12, 2019

I had another issue with dataclasses, they don't support extra fields even when you have Extra.ignore (the default), that's because the generated __init__ does not allow extra arguments, so I'm using BaseModel again.

Copy link

@samuelcolvin samuelcolvin commented Sep 12, 2019

We should make it clear that pydantic.dataclasses.dataclass is (mostly) a drop in replacement for dataclasses.dataclass with validation, not a replacement for pydantic.BaseModel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants