Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Basics
As before, objects are populated by default.
The
del
statement, which used to be completely broken, can now be used to clear an individual value.Internally, we have the
Undefined
singleton as a placeholder to indicate the absence of a value.(Note: The internals of
_data
are subject to change and should be considered an implementation detail.)Attempting to access a nonexistent value through an attribute will raise an error that is a subclass of
AttributeError
.There are two new parameters recognized by
import_loop
:init_values
: What to do with missing valuesTrue
: initialize toNone
False
: leave asUndefined
(default)apply_defaults
: What to do with fields' defaultsTrue
: honor themFalse
: ignore them (default)Normally,
Model.__init__()
overrides both of these. Its arguments includeinit=True
, which is just a shortcut for setting bothinit_values
andapply_defaults
at once when creating a new instance.So, to avoid pre-populating the model, one can specify
init=False
:Obviously,
init_values
andapply_defaults
can also be set independently.Field defaults
Presently, Schematics turns
None
values into the fields' respective defaults on every import and even during validation, which IMO is plainly a bug.As of this PR, these issues are fixed by virtue of
(i.e.,
None
in the input is now considered an explicit value that will not be replaced)apply_defaults
turned off by default (as it's mainly useful during__init__
only).Controlling what to export
There's a new option
export_level
that can appear in field definitions and model options. It supersedesserialize_when_none
.The default level is inherited from the base class options.
serialize_when_none
remains as a (deprecated) synonym forexport_level
:True => DEFAULT
,False => NONEMPTY
.export_level
can also be passed as an argument to export methods, in which case it will override any field- and model-level settings. In this capacity, it replacesprint_none
, which is removed.Missing values appear as
None
when exported.The model interface
keys()
,values()
,items()
, and__len__()
exclude unset fields.By contrast,
atoms()
exposesUndefined
placeholder objects, as its purpose is to iterate over all fields and serializables.Compatibility
Existing tests continue to pass unchanged except for
del
statement, which only recently got fixed anywayprint_none
parameter toexport_loop
.Breaking changes are mainly about fixing weird behaviors, most notably the habit of default values to reappear at every turn.