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