[Python-ideas] Json object-level serializer

[Daniel Fetchinson]

>>> Each individual time this question comes up people tend to react with
>>> "oh, that's too complicated and overkill, but magic methods are
>>> simple, so let's just define another magic method". The sum total of
>>> all those magic methods starts to accumulate into a lot of complexity
>>> of its own though :P
>>
>> 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).
>
>> And I don't see how generic functions bring less cognitive overhead.
>> (they actually bring more of it, since most implementations are more
>> complicated to begin with)
>
> Mostly because the fully fledged generic implementations like
> PEAK-rules tend to get brought into discussions when they aren't
> needed. Single-type generic dispatch is actually so common they gave
> it a name: object-oriented programming. All single-type generic
> dispatch is about is having a registry for a particular operation that
> says "to perform this operation, with objects of this type, use this
> function". Instead of having a protocol that says "look up this magic
> method in the object's own namespace" (which requires a) agreement on
> the magic name to use and b) that the original author of the type in
> question both knew and cared about the operation the application
> developer is interested in) you instead have a protocol that says
> "here is a standard mechanism for declaring a type registry for a
> function, so you only have to learn how to register a function once".
>
> 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)
>
> than it is for them to figure out that implementing a __json__ method
> will allow them to change how their object is serialised? (Not to
> mention that a __json__ method can only be used via monkey-patching if
> the type you want to serialise differently came from a library module
> rather than your own code).
>
> 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.
>
> Function registration is a solved problem, with much better solutions
> than the ad hoc YAMM (yet-another-magic-method) approach we currently
> use. We just keep getting scared away from the right answer by the
> crazily complex overloading schemes that libraries like PEAK-rules
> allow.


+1 on your entire diagnosis. If peak-rules is too complicated and
perhaps unmaintained then the focus should be on cooking up a better
generic function library. The complaints against peak-rules comes up
frequently enough and this shows that there is a need for a generic
function library because people do use peak-rules. The problem is not
with the concept but only (perhaps) with this particular
implementation (disclaimer: I'm perfectly happy with peak-rules).

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown