On Mon, Jul 6, 2020 at 10:11 PM Jon Ribbens via Python-list <python-list@python.org> wrote: > > On 2020-07-06, Chris Angelico <ros...@gmail.com> wrote: > > On Mon, Jul 6, 2020 at 8:36 PM Adam Funk <a24...@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? https://docs.python.org/3/library/pprint.html 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
