You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
from __future__ importannotationsfromtypingimportListfrompydantic.dataclassesimportdataclass@dataclassclassNode:
children: List[Node]
Node.__pydantic_model__.update_forward_refs()
Node(children=[Node(children=[])]) # Case 1.Node(children=[dict(children=[])]) # Case 2.
Case 1 in the sample script works as expected with Pydantic v1.8.2. In Pydantic 1.9.0, that upgrade being the only change to the environment, it produces this validation error:
children -> 0
value is not a valid dict (type=type_error.dict)
Case 2 works with both versions of Pydantic, indicating that the validation error message as such is correct.
I conclude that Pydantic v1.9.0 breaks support for Pydantic dataclasses as field data types on themselves (recursive nesting), for the case of input in the form of dataclass instances (case 1), which was a useful feature for unit testing. I have found no announcement in the change log that this is intentional.
The text was updated successfully, but these errors were encountered:
EDIT: I'll check this weekend if I can. @uriyyo do you have time to have a look on this? You'll probably be way faster and more accurate to find the right fix ;)
Checks
Bug
Output of
python -c "import pydantic.utils; print(pydantic.utils.version_info())"
:Minimal reproducing script:
Case 1 in the sample script works as expected with Pydantic v1.8.2. In Pydantic 1.9.0, that upgrade being the only change to the environment, it produces this validation error:
Case 2 works with both versions of Pydantic, indicating that the validation error message as such is correct.
I conclude that Pydantic v1.9.0 breaks support for Pydantic dataclasses as field data types on themselves (recursive nesting), for the case of input in the form of dataclass instances (case 1), which was a useful feature for unit testing. I have found no announcement in the change log that this is intentional.
The text was updated successfully, but these errors were encountered: