Upcoming Changes in V1 #153
rnag
started this conversation in
Dataclass Wizard V1
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I want to add my thoughts on planned (breaking) changes in the next major release V1.
Planned Changes
snake_case
, then in JSON output it will also be insnake_case
.JSONPyWizard
, as it was only a stop-gap solution.JSONWizard
should be the default class name, it is time to do away with alias toJSONSerializable
, which IMO doesn't make much sense to retain in a library called Dataclass Wizard.__str__()
will no longer be default (or at least the same) onJSONWizard
subclass.pydantic
does it weirdly, it prints the field names withrepr
'd values separated by a space, and no class name. Maybe there's a middle ground or it could involve leveragingpprint
. I'll have to think on it.float
value or a float instr
(ex.123.4
or'12.3'
) to anint
if the annotated type isint
. There seems to be lot of concern over this and it appears to be tied around unintentional data loss, and I agree, we shouldn't lose the fractional part when converting toint
, especially as Python we should strive to be more explicit and not do "silent" conversions like these.@dataclass
decorator may no longer be required? For convenience, our library can use@dataclass_transform
and apply it ourselves if a class isn't decorated with it. Especially true as most IDEs like PyCharm now support it. I think this would be a huge help for users, and me personally, as I sometimes forget to apply@dataclass
.__pre_as_dict__()
hook)Performance improvements
as_str()
is unnecessary, simply using builtinstr()
appears to be the fastest approach. What a shocker 😮None
when loading tostr
type. Something like'' if x is None else str(x)
seems like a good middle ground to have 🤔LoadMixin
should now return a string instead of be defined as regular functions, this will boost performance as we nowexec
function anyway, so there's no need to nest functions when parsing individual fields.DumpMixin
anddumpers.py
. My reasoning is, perhaps by default we can use the type annotations on a field to determine how to dump/serialize it. For example, if annotated type isstr | None
, then havekwargs[field] = value
in string code to return the field value, no need to check the type of value as howdataclasses
does it, e.g.if type(obj) in _ATOMIC_TYPES: ...
each timeasdict
is called. Though my follow-up thought was, it will prove tricky for cases likeOptional
andUnion
. ForUnion
type annotated fields, maybe it's best to check the type of value directly after all.parsers.py
can be removed, as they will be unnecessary.for
loop. I am thinking maybe having aMeta
setting such asinput_letter_case
or similar, so e.g. if set toinput_letter_case='CAMEL'
, then it will enable automatically mapmy_str
dataclass field tomyStr
in input JSON object. Plus of course, another setting such aswizard_mode=True
orauto_key_transform=True
would effectively disable "minor optimization" mode and loop over the input JSON object, as this library is currently doing it, and as the example on the frontpage of the docs clearly illustrates to users.I had more changes planned, if I remember them I will add or jot them down here. Thanks all, and kindly let me know any comments or feedback down below! 👋
Beta Was this translation helpful? Give feedback.
All reactions