cescu...@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
--
https://mail.python.org/mailman/listinfo/python-list
