Setting aside the arguments for just having reusable linked data JSON-LD in the first place (which is also JSON that a non JSON-LD app can pretty easily consume), A few questions then are:
Should __json__() be versioned? Should __json__() return JSON5 (with IEEE 754 ±Infinity and NaN)? 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__()? On Wednesday, August 14, 2019, Andrew Barnert <abarn...@yahoo.com> wrote: > On Aug 14, 2019, at 19:48, Wes Turner <wes.tur...@gmail.com> wrote: > > > > Native serialization and deserialization support for either or both > JSON5, JSON lines, and JSON-LD would be great to have. > > PyPI has packages for all of these things (plus the two > not-quite-identical variations on JSONlines, and probably other > JSON-related formats as well, not to mention alternative packages for JSON > itself that are better for various special uses, like pull-parsing giant > docs). > > I don’t think that there’s any particular reason any of them need to be > included in the stdlib. Especially since at least some of them are still > improving at a rate much faster than the stdlib can. > > It might make sense for the json module docs to mention some of the > related formats. But since none of the packages looks like a category > killer, I don’t think that could come with links to specific packages to > handle any of them, just descriptions of what they are and why they’re not > the same thing as JSON. > > And even that might not be necessary. Most people looking for JSON > actually do need JSON, not, say, JSON-LD, and people who do need JSON-LD > probably know they need it, won’t expect a module called json to provide > it, and can go find a library for it themselves. > > Still, if Python had the “loose recommendations from core devs” links > thing discussed in another thread, some of these packages might qualify. If > someone really wants that, they should probably read over what’s been said > about it so far and start a separate thread. > > > >
_______________________________________________ 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/6OZSGA3CG727GXPTQFFR2T5Q3F6AORBS/ Code of Conduct: http://python.org/psf/codeofconduct/
