This makes very explicit what essentially was an unintended (but perhaps fine) behavior that's currently in the library: the top-level isn't always a dict.
That was (is?) the basic assumption, but the way NestedMutable is implemented (to support easy nesting), the top-level for that one was allowed to be a list rather than a dict, creating a weird difference between the nested mutable and 'flat mutable'.
The databases seem to be fine with JSON arrays as the top level, so I'm not sure this library should arbitrarily stick to just objects. And even RFC 4627 supports both arrays and objects at the top level, so this seems in line with that and should be supported.
This makes very explicit what essentially was an unintended (but perhaps fine) behavior that's currently in the library: the top-level isn't always a
dict
.That was (is?) the basic assumption, but the way
NestedMutable
is implemented (to support easy nesting), the top-level for that one was allowed to be a list rather than a dict, creating a weird difference between the nested mutable and 'flat mutable'.The databases seem to be fine with JSON arrays as the top level, so I'm not sure this library should arbitrarily stick to just objects. And even RFC 4627 supports both arrays and objects at the top level, so this seems in line with that and should be supported.