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

There are many, many design decisions that would need to be made. Off the top of my head: what about recursive data structures? And basically every other decision ever made by pickle over the years.

My suggestion would be to write a package to do this yourself, then upload it to PyPI. I think functools.singledispatch would be a good building block.

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

I'd be even more opposed to a a "serialize but not deserialize" version going into the standard lib.

Eric