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.
Eric
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JLKVSEPS7PPAO4ETJ7GDMSVP3IKIL5N4/
Code of Conduct: http://python.org/psf/codeofconduct/
