> 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.
_______________________________________________ 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/EUA3ATHUVYI7RY27I4WJUME7BV473CQD/ Code of Conduct: http://python.org/psf/codeofconduct/
