On Tue, Apr 7, 2020 at 4:48 AM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote: > That’s not true for JSON; the entire point of it is data interchange. You > expect to be able to dump an object, send it over the wire or store it to a > file, load it (or even parse it in JS or ObjC or Go or whatever) and get back > an equivalent object. It’s easy to come up with ways to build on top of JSON > to interchange things like time points or raw binary strings or higher-level > structured objects, but they require doing something on both the encode side > and the decode side. Just being able to encode them to something > human-readable is useless—if I encode a datetime object, I need to get back a > datetime (or Date or NSDate or whatever) on the other end, not a str (or > string or NSString or whatever) that a human could tell is probably meant to > be a datetime but will raise an exception when I try to subtract it from > now(). > > (Of course JSON isn’t perfect, as anyone who’s tried to interchange, say, > int64 values discovers… but it’s good enough for many applications.) >
The trouble with using JSON to interchange things that aren't in the JSON spec is that you then have to build another layer on top of it - a non-standard layer. That means that whatever you do, it's inherently app-specific. For instance, I might choose to encode a datetime as a string in ISO format, but how is the other end going to know that it was meant to be a date? (Usually, if I'm sending something to some front-end JavaScript, I'll just hard-code the JS to know that thing[0].created is a timestamp, and should be parsed accordingly.) So if it's app-specific, then the best way to handle it is in your app, not in the data type you're encoding. Subclassing JSONEncoder works for this; adding a __json__ method doesn't really, unless there is some single canonical encoding for a particular object. The two become close to equivalent when you're only asking about your own custom classes. You can, in fact, create your own private __json__ protocol (although, since it's private to you, it'd probably be better to call the method "to_json" rather than "__json__"), and have a subclass of JSONEncoder that calls it. It'd work fine because you don't NEED to interoperate with other libraries. It's only when you try to standardize something that's inherently nonstandard that things get problematic :) ChrisA _______________________________________________ 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/4ZEQKTQ5CMZUXC6E6JVFHQS3VGYEDJ7C/ Code of Conduct: http://python.org/psf/codeofconduct/
