On Apr 6, 2020, at 11:54, Dan Cojocaru firstname.lastname@example.org 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.