Python object > JSON  > object requires type information to be serialized. 

Jsonpickle is two-way; with support for numpy, pandas, JS, datetimes, UUIDs, and IDK about e.g. complex fractions

JSONLD can specify type information in a space-efficient way with @context (rather than having to specify e.g. @type=xsd:boolean for every boolean value)
JSONLD includes @type URIs that can be e.g. XSD datatypes or types.

- JSON is an ECMA spec.
- jsonpickle has a python and a js implementation
- JSON5 is an unofficial spec with many implementations
- JSONLD 1.1 is a W3C candidate recommendation with many implementations (pyld, rdflib-jsonld, )

In order to optionally serialize to any of {JSON, JSON5, JSONLD, JSON_future}, we could:

A) accept an optional parameter on a __json__ method: __json__(obj, spec=None)

B) establish a convention for registering functions to call with singledispatch in a default method

?) Other ideas?

On Mon, Apr 6, 2020, 12:22 PM Dan Cojocaru <> wrote:
Addressing your last concern, about __json__ being only class -> JSON, not JSON -> class, classes implementing __str__ only go class -> str, not str -> class. Just because we can't fully solve a problem, it doesn't mean we shouldn't attempt to solve (or provide a more convenient to solve) half of it.

Dan Cojocaru
On 6 Apr 2020, 19:02 +0300, Christopher Barker <>, wrote:
On Mon, Apr 6, 2020 at 8:27 AM Wes Turner <> wrote:
This thread discusses a __json__ encoder protocol:

"adding support for a "raw output" in JSON serializer"

and a numbe rof other issues :-)

This would be a really good time for someone to go through this list and maybe others), and summarize all the discussions around __json__

FWIW, the idea of a __json__ protocol has support, but it's not clear to me if there wasn't interest by core devs, or if it's just that no one has cleaned the discussion up and made it into a clean proposal to be considered.

Note that there IS notable overhead to adding a new dunder like that -- there will be (legitimate) resistance.

> JSON5 allows things like ±inf and nan.

For my part, I would REALLY like to see the stdlib json module support JSON5 -- it better matches Python. (inf, comments, and trailing commas -- ALL things I really miss with JSON)

Second on my list would be support for Decimal, as that matches teh JSON data model (nothing in there about binary floating point).

As for __json__ -- I get it, but I think I'm -0.5: because it's a one way street -- of you want to go from custom object => JSON, iot's great, but the other way doesn't work, so you'll need to do SOMETHING custom there anyway. So having the JSON module fully support a mapping between the JSON types and Python seems enough to me.


Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: