There's JSON5; which supports comments, trailing commas, IEEE 754 ±Infinity and NaN, [...]

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.

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 <> wrote:
On Aug 14, 2019, at 11:38, Chris Angelico <> 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 --
To unsubscribe send an email to
Message archived at
Code of Conduct: