On 6/10/2020 11:59 AM, J. Pic wrote:
> 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".
My reason: because it's yet something else to maintain in the standard library, and doesn't add enough value to justify its existence and ongoing maintenance cost.

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.