I don't think the stdlib needs to cater to that requirement when there are hooks to write your own customizations.
If the stdlib offers such hooks, as well as objects that don't serialize by default, why not ship a usable hook that would serialize anything from the stdlib by default ? It really seems like it "almost got there".
Perhaps the stdlib JSONEncoder could check for a new __json__ method on every object it serializes. Similar to __getstate__, __json__ should however return data that only contains json-compatible types. Then we could go on and add it for stdlib objects such as uuid and datetime, and have a rudimentary but failsafe json dumpsing function that works with any python object from the stdlib, as well as your own objects where you add a __json__ magic method.
IMO, it's worse than that.
Agreed that JSON deserialization is a problem I would rather not even try to solve actually. Choosing what type to deserialize with seems like a problem that doesn't have an elegant solution:
- even with a schema: what if an attribute has different types within the same list, then the schema will not work or have to be complex - storing the types into the encoded output like Pickle, but that changes the schema and might also be subject to the same security warnings that Pickle has
So, custom-typed deserialized doesn't look like something that could get in the stdlib.
That said, rudimentary and failsafe JSON serialization seems reachable and still useful.