New JSON encoding method proposal for custom objects

Peter Otten __peter__ at web.de
Sun Nov 29 10:46:13 EST 2015


cescus92 at gmail.com wrote:

> Hello everyone!
> 
> I'm writing here since I've read on the Pyhton's documentation that this
> is the most common path that a new proposal should follow. I'd be really
> glad if this proposal could become a PEP if I see a good response from the
> community or, in the worst case, understand why this proposal is not good
> enough.
> 
> In this day I stumbled upon a very simple task: I had a list of instances
> of a custom class and I had to convert i into a JSON.
> 
> Actually, from what I've discovered, there are 2 ways to get the JSON out
> of a custom non serializable instance: - defining a new method ( e.g.
> to_json() ) inside the class that converts the item manually (quicker) - a
> custom encoder/decoder that goes to extend the ones from the json lib
> (cleander, I think)
> 
> Since I thought it was the most cost-effective and I was in hurry, I took
> the first way that drove me to a "problem": if I wanted to get the JSON
> out from my list, it obviously would have given me the "non serializable
> object" error since the json lib didn't know how to transform it into
> JSON!
> 
> I was astonished that Python was requiring me such ugly ways to accomplish
> this simple task! JSON WebServices are becoming more and more popular and
> Python _must_ keep the pace of time! And here it is my proposal to make
> this task easier in the best Pythonic way :)
> 
> I propose that every custom class that wants to allow its instances to
> have a JSON representation could implement a simple method, __json__().
> 
> The way how it works it very straightforward: every time json lib is
> required to convert an object that doesn't know, it looks for the
> __json__() method to learn how to treat the object. The duty of this
> method should be to reduce the complexity of an object instance into an
> elementary data type (int, str, list, dict, etc..).
> 
> Often the process to get the JSON out of an object is a one-way need, in
> this way it would become even simpler to do it in the most flawless way so
> the programmer should no more care to implement some custom logic to
> handle quickly these situations.
> 
> Let me give you a very small example of what a __json__ method could be
> like:
> 
> class CustomObj():
>   def __init__(self, p1, p2):
>     self.p1 = p1
>     self.p2 = p2
> 
>   def __json__(self):
>     return {
>       'p1': self.p1,
>       'p2': self.p2
>     }
> 
> Once more, the job of __json__ should simply be the one of make our object
> json-readable :)
> 
> What do you think of it? Do you think it's good? If not, why?

I'm not sure if that is needed often enough so that adding yet another 
__dunder__ method is worthwhile, particularly as the current mechanism 
already makes an implementation of your idea a matter of a few lines:

>>> import json
>>> class Encoder(json.JSONEncoder):
...   def default(self, obj):
...     try: encode = obj.__json__
...     except AttributeError: return super().default(obj)
...     return encode()
... 
>>> class Foo:
...     def __json__(self): return dict(bar=1, baz=2)
... 
>>> json.dumps({1:2, 3:Foo()}, cls=Encoder)
'{"1": 2, "3": {"baz": 2, "bar": 1}}'

Personally I would find it more interesting if there were a unified 
mechanism for json and pickle. At the very least you should come up with a 
decoding mechanism.

> Do you have any guidance to make this idea advance?

Go to python-ideas for a lengthy discussion ;)

> Do you advice me to write down a preliminary PEP or to make directly a
> pull request to the Python's source code?
> 
> Thank you for you're time!
> I'm waiting for your feedback :)
> Have a good Sunday!
> 
> Francesco





More information about the Python-list mailing list