Just a random note, I actually set about the task of re-implementing a json encoder which can be subclassed, is highly extensible, and uses (mostly) sane coding techniques (those of you who've looked at simplejson's code will know why this is a good thing). So far preliminary tests show the json only subclass of the main encoder basically tied in performance with the python implementation of simplejson. The C version of simplejson does turn in a performance about 12x faster, but that's apples to oranges. The design of the encoder would also make a XML serializer pretty straight forward to implement as well (not that I care about XML, *blech*).
I'm torn between just moving on to some of my other coding tasks and putting some time into this to make it pass the simplejson/std lib json tests. I really do think the standard lib json encoder is bad and I would like to see an alternative in there but I'm hesitant to get involved. Nathan On Thu, Oct 27, 2011 at 11:24 AM, Amirouche Boubekki <amirouche.boube...@gmail.com> wrote: > > > 2011/10/27 Chris Rebert <c...@rebertia.com> >> >> On Wed, Oct 26, 2011 at 2:14 AM, Amirouche Boubekki >> <amirouche.boube...@gmail.com> wrote: >> > Héllo, >> > >> > I would like to fork simplejson [1] and implement serialization rules >> > based >> > on protocols instead of types [2], plus special cases for protocol free >> > objects, that breaks compatibility. The benefit will be a better API for >> > json serialization of custom classes and in the case of iterable it will >> > avoid a calls like: >> > >> >>>> simplejson.dumps(list(my_iterable)) >> > >> > The serialization of custom objects is documented in the class instead >> > of >> > the ``default`` function of current simplejson implementation [3]. >> > >> > The encoding algorithm works with a priority list that is summarized in >> > the >> > next table: >> > >> > +-------------------+---------------+ >> > | Python protocol | JSON | >> > | or special case | | >> > +===================+===============+ >> <snip> >> > | (§) unicode | see (§) | >> <snip> >> > (§) if the algorithm arrives here, call unicode (with proper encoding >> > rule) >> > on the object and use the result as json serialization >> >> I would prefer a TypeError in such cases, for the same reason >> str.join() doesn't do an implicit str() on its operands: >> - Explicit is better than implicit. >> - (Likely) errors should never pass silently. >> - In the face of ambiguity, refuse the temptation to guess. > > granted it's better. > > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
