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. 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.. > 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. > 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. 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. _______________________________________________ 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/5TRUZERK2R6VAGSO65SSJYXNXKD4O7KF/ Code of Conduct: http://python.org/psf/codeofconduct/
