> 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.