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
I'm confused about the behaviour of aggregate processors (dictionary and in particular user_object) when using required=False. Consider the following example:
I find the default value {} for missing optional dictionaries a bit strange. It's consistent with the primitive processors (that return e.g. '' instead of None or a missing dict key for strings), but it's counterintuitive to me that {'person': {}} is a valid input to the root processor, but {} is invalid for the person processor:
This becomes particularly annoying when it comes to optional user_object processors: when the corresponding element is omitted from the XML, the parser produces an instance of the custom class with no attributes set, which I would think is rarely meaningful.
In my current codebase I'm using the following workaround in my base model class, which results in missing objects parsing to None:
This could alternatively be achieved with an after_parse hook. Either way, though, it's not perfect: in the case where the subprocessor validates against an empty element, empty elements appear as if they are missing, and as far as I can tell there's no way to distinguish them. For example, if we set required=False on person.name, the documents <root /> and <root><person/></root> will parse to the same structure.
Changing the way optional processors work would obviously be a large breaking change, but what do you think about adding a default= parameter to dictionary, user_object (and maybe array)? Then users could simply specify default=None.
The text was updated successfully, but these errors were encountered:
I'm confused about the behaviour of aggregate processors (
dictionary
and in particularuser_object
) when usingrequired=False
. Consider the following example:I find the default value
{}
for missing optional dictionaries a bit strange. It's consistent with the primitive processors (that return e.g.''
instead ofNone
or a missing dict key for strings), but it's counterintuitive to me that{'person': {}}
is a valid input to the root processor, but{}
is invalid for the person processor:This becomes particularly annoying when it comes to optional
user_object
processors: when the corresponding element is omitted from the XML, the parser produces an instance of the custom class with no attributes set, which I would think is rarely meaningful.In my current codebase I'm using the following workaround in my base model class, which results in missing objects parsing to
None
:This could alternatively be achieved with an after_parse hook. Either way, though, it's not perfect: in the case where the subprocessor validates against an empty element, empty elements appear as if they are missing, and as far as I can tell there's no way to distinguish them. For example, if we set
required=False
on person.name, the documents<root />
and<root><person/></root>
will parse to the same structure.Changing the way optional processors work would obviously be a large breaking change, but what do you think about adding a
default=
parameter todictionary
,user_object
(and maybearray
)? Then users could simply specifydefault=None
.The text was updated successfully, but these errors were encountered: