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 <tjre...@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 > -- http://mail.python.org/mailman/listinfo/python-list
