Pydantic dataclasses do not respect the extra-fields in Config

[mvalkon]

Question

Pydantic dataclasses do not seem to respect the configuration passed in the @dataclass-decorator. I am wondering if this is a bug or expected functionality? The documentation indicates that the Config is respected.

pydantic.dataclasses.dataclass's arguments are the same as the standard decorator, except one extra keyword argument config which has the same meaning as Config.

In particular I would like to ignore extra fields when initialising the object. The documentation suggests that the default behaviour is Extra.ignore, but it does not seem to work. Making this explicit does not seem to have an effect either..

from pydantic.dataclasses import dataclass
>>> class C:
...     extra = Extra.ignore
...
>>> @dataclass(config=C)
... class Foo:
...     a: str
...     b: str
...
>>> Foo(**{"a": "bar", "b": "foo", "c": 1})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got an unexpected keyword argument 'c'

Please complete:

• OS: os x
• Python version:

>>> import sys; print(sys.version)
3.7.2 (default, Mar 22 2019, 11:08:57)
[Clang 10.0.0 (clang-1000.10.44.4)]

• Pydantic version:

>>> import pydantic; print(pydantic.VERSION)
1.0

[samuelcolvin]

This is a limitation of the standard dataclass implementation which pydantic uses, hence you can see the error is TypeError not a pydantic ValidationError.

I don't see a way around this since AFAIK dataclasses don't have an "allow extra arguments" option.

We should improve the documentation to describe which parts of Config dataclasses are able to respect and which don't work.

[samuelcolvin]

• title - should work fine, you'd need to use Foo.__pydantic_model__.schema() for now, see utility methods #481
• anystr_strip_whitespace - should work fine
• min_anystr_length - should work fine
• max_anystr_length - should work fine
• validate_all - should work fine (I think, might need to check)
• extra - as described won't work
• allow_mutation - should work but you'd need frozon=False on the dataclass
• use_enum_values - should work fine
• fields - unlikely to have much effect since aliases won't get past the dataclass's own checks
• validate_assignment - as with allow_mutation should work fine with frozon=False
• allow_population_by_field_name - probably won't work as with fields

[mvalkon]

@samuelcolvin thanks for the quick response. It makes complete sense. I suppose it would be possible to support this use case by filtering out fields that are not declared in the dataclass before instantiating the dataclass object though?

[samuelcolvin]

I guess. We might also want to respect aliases by mapping them to field names.

The problem is

https://github.com/samuelcolvin/pydantic/blob/b92e74d0a64156c2a388b149e569c5a5f7f8e136/pydantic/dataclasses.py#L84

We create a vanilla dataclass and I don't know of a way to intercept a dataclass "pre-init". Also we'd then have to implement our own logic to map args to kwargs.

To me this sounds unnecessarily complicated. If you want extra, best to use BaseModel.

[PrettyWood]

I guess we could do something like this

[DetachHead]

why was this closed? looks like @PrettyWood's solution is simple enough

[1pakch]

To me this sounds unnecessarily complicated. If you want extra, best to use BaseModel.

At the very least the docs should mention that the extra setting is ignored on dataclasses.
EDIT: It's a massive turn-off for using pydantic dataclasses in the context of FastApi

[DetachHead]

can this be closed now that #2557 was merged?