[Python-ideas] Json object-level serializer

[Alex Gaynor]

On Thu, Jul 29, 2010 at 5:39 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
>> > I don't agree. __json__ only matters to people who do JSON
>> > encoding/decoding. Other people can safely ignore it.
>>
>> Which is exactly the attitude I was talking about: for each individual
>> case, people go "oh, I understand magic methods, those are easy". It's
>> the overall process of identifying the need for and gathering
>> consensus on magic methods that is unwieldy (and ultimately fails to
>> scale, leading to non-extensible interfaces by default, with pretty
>> printing being the classic example, and JSON serialisation the
>> latest).
>
> Why do you want to gather consensus? There is a single json
> serialization module in the stdlib and it's obvious that __json__
> can/should be claimed by that module.
>
> Actually, your argument could be returned: if you use generic functions
> (such as @json.dumps.overload), alternative json serializers won't
> easily be able to make use of the information, while they could access
> the __json__ method like the standard json module does.
>
>> Is it really harder for people to learn how to write things like:
>>
>>     json.dumps.overload(mytype, mytype.to_json)
>>     json.dumps.overload(third_party_type, my_third_party_type_serialiser)
>
> It is certainly more annoying and less natural than:
>    def __json__(self): ....
>
> Sure, generic functions as a paradigm appear more powerful, more
> decoupled, etc. But in practice __magic__ methods are sufficient for
> most uses. Practicality beats purity.
>
> That may be why in all the years that the various generic functions
> libraries have existed, they don't seem to have been really popular
> compared to the simpler convention of defining fixed method names.
>
> (besides, it wouldn't necessarily be json.dumps that you overload, but
> some internal function of the json module; making it even less intuitive
> and easily discoverable)
>
>> The generic function registration approach is incidentally
>> discoverable via dir(json.dumps) to see that a function provides the
>> relevant generic function registration methods. Magic method protocols
>> can *only* be discovered by reading documentation.
>
> If help(json.dumps) includes a small blurb about __json__, it makes the
> information at least as easily discoverable as invoking dir(json.dumps).
>
> Besides, I don't find it shocking if documentation problems have to be
> solved through documentation.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>

I'd be -1 on an __json__ method.  From the perspective of someone who
works on Django, the big issue we have is how do you specify how a
model (something from the database) should be serialized to JSON.
Often people suggest something like __json__ that the Django
serializer (which uses the json module) could pick up on, however this
is usually rejected: objects tend to have multiple serializations
based on context.  Unlike pickle, which is usually used for internal
consumption, json is usually intended for the wide world, and
generally you want to expose different data to different clients.  For
example an event's json might include a list of attendees for an
authenticated client, but an unauthenticated client should only see a
list of titles.  For this reason Django has always rejected such an
approach, in favor of having a per-serialization specification.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me