On 10/28/2011 1:20 PM, Nathan Rice wrote:
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
Python is the result of people who thought *something* was 'bad'
and I would like to see an alternative in there
and volunteered the effort to make something better.
> but I'm hesitant to get involved.
As someone who is involved and tries to encourage others, I am curious why.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
