Forking simplejson

[Nathan Rice]

I've found that in a lot of cases getting a patch submitted is only
half about good engineering.  The other half is politics.  I like one
of those things, I don't like the other, and I don't want to take time
out of my coding schedule to write something if in the end a reviewer
shoots down my patch for contrived reasons.  I don't know what the
python committers are like but I guess you could say I'm once bitten
twice shy.

Nathan

On Fri, Oct 28, 2011 at 4:52 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 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
>