Open TomaszBorczyk opened 1 year ago
I've opened the PR to fix the issue.
If I might, I would like to start a conversation about caching - as there seems to have been (and are, and might be more) some issues that appeared because of caching, have you considered reverting those changes completely and dropping caching altogether? Would the performance hit be significant enough that you would rather keep the caching?
Asking as I do not know the historical context (maybe there was a need for performance boost)
@mciszczon @konradhalas
Describe the bug Exception is thrown in dacite when using
from_dict
in certain scenarios on dataclass with<type> | None
field, egstr | None
To Reproduce
Stack trace:
Root cause is caching of
dacite.types.is_generic_collection
anddacite.types.is_generic
- caching mechanism interprets bothOptional[str]
andstr | None
as the same value, so it returns wrong value when we first call it withOptional[str]
, and then call it withstr | None
. This means first call offrom_dict
withOptionalDataclass
pollutes the cache and breaks the behaviour forfrom_dict
withUnionDataclass
. Note that running onlydacite.from_dict(UnionDataclass, d2, config=c)
(without preceding call) works as expected.To prove this, below are even simpler reproduction steps that throw exception:
Below works just fine:
thus cache pollutes scope of dacite
Removing
@cache
fromis_generic_collection
,is_generic
andextract_origin_collection
fixes the issue in both casesExpected behavior Dacite transforms the data without error
Environment
dacite
version: 1.8.1Workaround Downgrade is an option - dacite@1.7.0 works correctly