On Mon, Apr 6, 2020 at 9:18 AM Dan Cojocaru <dan.cojocar...@e-uvt.ro> 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! -CHB > > --- > Dan Cojocaru > On 6 Apr 2020, 19:02 +0300, Christopher Barker <python...@gmail.com>, > wrote: > > On Mon, Apr 6, 2020 at 8:27 AM Wes Turner <wes.tur...@gmail.com> wrote: > >> This thread discusses a __json__ encoder protocol: >> >> "adding support for a "raw output" in JSON serializer" >> >> https://mail.python.org/archives/list/python-ideas@python.org/thread/WT6Z6YJDEZXKQ6OQLGAPB3OZ4OHCTPDU/ >> > > 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. > > -CHB > > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/ZYUBQCAFHL2WHEVFVEMOM5JS6AFZDDEK/ Code of Conduct: http://python.org/psf/codeofconduct/
