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