On Mon, Apr 6, 2020 at 9:18 AM Dan Cojocaru firstname.lastname@example.org 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.
That's why I'm only -0.5 :-)
But __str__ is pretty key to a lot of Python usage, for every type of object, etc. JSON is a far more specialized use case. Which I think is the argument against it: it's adding overhead to a lot, in order to support one particular special use case.
Anyway, my primary suggestion at this point, if someone wants to pursue this, is to go back and gather all the arguments for and against that have already been made -- there really has been a LOT of discussion about this already!
Dan Cojocaru On 6 Apr 2020, 19:02 +0300, Christopher Barker email@example.com, wrote:
On Mon, Apr 6, 2020 at 8:27 AM Wes Turner firstname.lastname@example.org 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
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython