[Python-ideas] Json object-level serializer

Nick Coghlan ncoghlan at gmail.com
Sat Jul 31 03:31:49 CEST 2010

On Sat, Jul 31, 2010 at 11:17 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Suppose I write a class Foo, and as a convenience to my users,
> I want to give it the ability to be json-serialised. If that
> is done using a generic function, then I need to put a call
> in my module to register it. But that makes my module dependent
> on the json-serialising module, even for applications which
> don't use json at all.
> The alternative is just to provide the function but don't
> register it. But using that approach, every application that
> *does* use json would be responsible for registering all the
> functions for all the classes that need to be serialised,
> including those in library modules that it may not be directly
> aware of. This doesn't seem like a good situation either.

Hence why most generic function proposals are accompanied by proposals
for lazy module import hooks (i.e. delaying the registration until the
relevant module is imported).

However, the simpler approach is just to recommend that
single-dispatch generic functions default to a particular method.
"magic method" vs "generic function" isn't actually an either-or
decision: it is quite possible to have the latter rely on the former
in its default "unrecognised type" implementation, while still
providing the type registration infrastructure that allows an
application to say "no, I don't want that behaviour in this case, I
want to do something different".

To be honest, there are actually some more features I would want to
push for in ABCs (specifically, a public API to view an ABC's type
registry, as well as a callback API to be notified of registration
changes) before seriously proposing an official generic function
implementation in the standard library.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list