On Thursday, August 15, 2019, Andrew Barnert <abarn...@yahoo.com> wrote:
> On Aug 14, 2019, at 20:35, Wes Turner <wes.tur...@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? https://github.com/python/cpython/blob/master/Modules/_json.c https://devguide.python.org/experts/ : > 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.
_______________________________________________ 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/KOBOHDV77OATGI7ND36LJ4IOSFZWG7JC/ Code of Conduct: http://python.org/psf/codeofconduct/
