Forking simplejson

[Nathan Rice]

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.boubekki at gmail.com> wrote:
>
>
> 2011/10/27 Chris Rebert <clp2 at rebertia.com>
>>
>> On Wed, Oct 26, 2011 at 2:14 AM, Amirouche Boubekki
>> <amirouche.boubekki at 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
>
>