On Mon, Jul 6, 2020 at 10:11 PM Jon Ribbens via Python-list
<python-list at python.org> wrote:
> On 2020-07-06, Chris Angelico <rosuav at gmail.com> wrote:
> > On Mon, Jul 6, 2020 at 8:36 PM Adam Funk <a24061 at ducksburg.com> wrote:
> >> Is there a "bulletproof" version of json.dump somewhere that will
> >> convert bytes to str, any other iterables to list, etc., so you can
> >> just get your data into a file & keep working?
> > That's the PHP definition of "bulletproof" - whatever happens, no
> > matter how bad, just keep right on going.
> While I agree entirely with your point, there is however perhaps room
> for a bit more helpfulness from the json module. There is no sensible
> reason I can think of that it refuses to serialize sets, for example.
Sets don't exist in JSON. I think that's a sensible reason.
> Going a bit further and, for example, automatically calling isoformat()
> on date/time/datetime objects would perhaps be a bit more controversial,
> but would frequently be useful, and there's no obvious downside that
> occurs to me.
They wouldn't round-trip without some way of knowing which strings
represent date/times. If you just want a one-way output format, it's
not too hard to subclass the encoder - there's an example right there
in the docs (showing how to create a representation for complex
numbers). The vanilla JSON encoder shouldn't do any of this. In fact,
just supporting infinities and nans is fairly controversial - see
other threads happening right now.
Maybe what people want is a pretty printer instead?
Resilient against recursive data structures, able to emit Python-like
code for many formats, is as readable as JSON, and is often
round-trippable. It lacks JSON's interoperability, but if you're
trying to serialize sets and datetimes, you're forfeiting that anyway.