In v0 this PR aligned lib behaviour with marshmellow, but effectively triggered a couple of unexpected consequences:
People using from_json will start noticing builtin types being implicitly converted when reading json files into dataclasses, and especially booleans receiving valid values from not-very-common-sense values like integers outside 0-1 range and strings
People using from_dict will have even "better" experience when types in their dicts are being overridden by dataclass field type, with implicit conversion as a side-effect
People using marshmellow interop would rejoice
Possible solution
First of all, we should add a flag for implicit coercions:
[tool.dataclasses_json]
coerce_builtins = True
Second, we should do a follow-up discussion re coercion behaviours in from_dict, IMO this should differ from from_json behaviour because from_dict argument carries type information, while from_json has to work with a string.
Description
In v0 this PR aligned lib behaviour with marshmellow, but effectively triggered a couple of unexpected consequences:
from_jsonwill start noticing builtin types being implicitly converted when reading json files into dataclasses, and especially booleans receiving valid values from not-very-common-sense values like integers outside 0-1 range and stringsfrom_dictwill have even "better" experience when types in their dicts are being overridden by dataclass field type, with implicit conversion as a side-effectPossible solution
First of all, we should add a flag for implicit coercions:
Second, we should do a follow-up discussion re coercion behaviours in
from_dict, IMO this should differ fromfrom_jsonbehaviour becausefrom_dictargument carries type information, whilefrom_jsonhas to work with a string.Alternatives
N/A
Context
Problem discovered in https://github.com/lidatong/dataclasses-json/issues/466