On Apr 6, 2020, at 11:54, Dan Cojocaru <dan.cojocar...@e-uvt.ro> wrote: > > > I totally agree, but the JSONEncoder/JSONDecoder mechanism already exist. I'm > certainly removing stuff. I'm just proposing adding a simpler way to do one > of the things - serialising. An example use case would be creating a simple > class for something like a REST API and that class having a __json__ > function. Python doesn't need to deserialise the JSON, so you only need one > half of the story, the half that __json__ would make easier.
For the vast majority of people writing web services, they’re already using a bunch of third-party libs. If they’re not using a framework that does its own JSON-izing, they can pick simplejson or some other third-party library they prefer. What about people who are writing a web service with no third-party libraries? Well, I think that’s a pretty rare use case, and a pretty specialized/expert one. And what’s the cost for them today? It takes 3 lines of code In your handler to call the __json__ method manually. And there’s a lot more flexibility. Have a bunch of already-written classes that you don’t want to edit? Use @singledispatch instead of a method protocol. Have a bunch of existing code from another project that used simplejson? Use its tojson protocol, and you don’t need to fork every class just to change the name. And so on. _______________________________________________ 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/NWEQYAIINMAX6ZOJKY2A7XDUPLJVK5YF/ Code of Conduct: http://python.org/psf/codeofconduct/
