On Thursday, August 15, 2019, Andrew Barnert <abarnert@yahoo.com> wrote:
On Aug 14, 2019, at 20:35, Wes Turner <wes.turner@gmail.com> wrote:
> A few questions then are:
>
> Should __json__() be versioned?
Why? While there are sort of multiple versions of JSON (pre-spec, ECMA404, and the successive RFCs), even when you know which one you’re dealing with, there’s not really anything you’d want to do differently as far as returning different objects to be serialized. You might return different objects based on the allow_nan flag, and if the proposed use_decimal is added, even more likely—but those aren’t controlled by the JSON version.
So, there is opportunity for JSON library developers to write a PEP that standardizes the argument specifications (maybe as optional **kwargs) for e.g. ._json() or .for_json() so that flags like allow_nan and use_decimal MAY BE honored.
And then, years later, we can implement that in the standard library, too?
Originally, oddly, sorry I can't remember where the standard library JSON module came from? Someone donated and relicensed it; IIRC. Is it sinplejson?
> json bob.ippolito (inactive), ezio.melotti, rhettinger
And meanwhile, you seem to be expecting that one of the many JSON-based and JSON-like formats is going to become an official successor to JSON and take over its ubiquity. But that really isn’t likely (and you aren’t going to make it any more likely by arguing for it on python-ideas, and even less so by arguing for four of them at once, which all pull in different directions). And, even if it did happen, it wouldn’t be a next version of JSON. And, even if it were, there’s nothing code could do with a version number today to take advantage of whatever format becomes available in the future, given that nobody could guess what format that might be. So there’s no advantage to adding this now..
So, ±Infinity are or are not supported?
> Should __json__() return JSON5
Definitely not. Just because JSON5 is a superset of JSON doesn’t mean you can produce JSON5 and give it to services, programs, etc. expecting JSON, any more than you can give them YAML 1.1 or JavaScript source or any other superset of JSON. This would make the JSON module unusable for 99.9999% of its existing uses.
So, instead third-party libraries and eventually stdlib json could have ._json_(spec='json5') where spec='json5' and allow_nan=True
._json_(spec='json5')
._json_(spec='json5', allow_nan=True) #redundant
._json_(spec='json5', use_decimal=True) #redundant but necessary for backwards compatibility (*)
> What prevents existing third-party solutions for encoding/serializing/marshalling/dumping and decoding/deserializing/ubmarshalling/loading JSON, JSON5, and JSON-LD from standardizing on e.g. __json__(), __json5__(), and __jsonld11__()?
The fact that __dunder__ names are reserved for Python itself and Python implementations. This is why simplejson changed its protocol to use a method named for_json.
The Jupyter rich display object protocol _repr_json_() does not support kwargs at this time; practically,
where would use_decimal be specified in a notebook?
Other than that, this really isn’t a question for python-ideas. it’s a question for the authors of the existing third-party solutions. If there are three different JSON-LD packages and they all have a “here’s a substitute object to serialize” protocol but they’re not compatible with each other, file bugs against those packages asking them to be compatible with each other. Either that, or go out into the world and proselytize for one of them to get it to “category killer” status so the others either go away or adopt its de facto standard.
It would be helpful to have a - even a rejected but widely implemented - PEP specifying the method name and kwargs that standard library and third-party solutions MAY implement for JSON serialization.