On Wednesday, August 14, 2019, Wes Turner <wes.tur...@gmail.com> wrote:
> There's JSON5; which supports comments, trailing commas, IEEE 754 > ±Infinity and NaN, [...] > https://json5.org/ > > There's also JSON-LD, which supports xsd:datetime, everything that can be > expressed as RDF, @context vocabulary, compact and expanded > representations, @id, and lots of other cool features that formats like > CSVW utilize. > > https://json-ld.org/spec/latest/ > (Edit) https://www.w3.org/TR/json-ld11/ > A JSON-based Serialization for Linked Data > > https://www.w3.org/TR/tabular-data-primer/ > > It seems like just yesterday we were adding JSON to the standard library. > Is there a way to save pickles without allowing executable code to be > stored or executed at deserialization time? PyArrow is fast, there's also a > JS implementation, does SIMD, and zero-copy reads. > > Native serialization and deserialization support for either or both JSON5, > JSON lines, and JSON-LD would be great to have. > > On Wednesday, August 14, 2019, Andrew Barnert via Python-ideas < > python-ideas@python.org> wrote: > >> On Aug 14, 2019, at 11:38, Chris Angelico <ros...@gmail.com> wrote: >> > >> > Side point: Does anyone else think it was an egotistical idea to >> > create JSON as a non-versioned specification? "I can't possibly get >> > this wrong". And now look what's happened. >> >> Well, it was supposed to be an antidote to complicated specifications >> like XML. The syntax fits on a yellow sticky note (sort of), the semantics >> are “whatever your browser’s eval says”, and nobody’s ever going to use it >> for anything but passing around DHTML info. Even though Crockford and >> friends were using it to pass that info from Java services to a JS client >> pretty early on, they didn’t even have a JSON library for Java, just >> hand-written format strings they filled with the data. >> >> So, the idea that there might one day be a series of three RFCs (plus >> ECMA and ISO specs) was probably not so much horrifying as laughably >> implausible. >> >> Of course now the world has learned its lesson, so nobody will ever do >> that again. YAML and TOML have version numbers, even if they don’t mean >> what you expect and there’s no way to tell what version number a given >> document is. BSON has 1.0 and 1.1, each of which matches some specific >> version of JSON., even if that version isn’t specified anywhere, and, while >> there’s no way to tell which version a given document was written in, 1.1 >> is “mostly” backward compatible, so that’s good enough, right? The various >> non-XML RDF/semantic-triple notations mostly don’t have their own versions, >> but at least if you search hard enough you can find which version of RDF >> they currently notate and hope that hasn’t changed since the document was >> created. MessagePack has a version field, even if it’s optional and >> deprecated and version numbers were localtimes that couldn’t be looked up >> anywhere. Avro is intentionally unversioned because it will never change, >> according to version 1.8 of the spec. And so on. We’re in great shape for >> the future. :) >> _______________________________________________ >> 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/archiv >> es/list/python-ideas@python.org/message/HT6DRWL6ODCJ5MFO7ZU7POALIZ4Q3FU2/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ 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/7JQGEVQ5FQ6BKYUWUHIM7DJSBPVA5XYQ/ Code of Conduct: http://python.org/psf/codeofconduct/
