[Python-Dev] Status of json (simplejson) in cpython (original) (raw)

Xavier Morel python-dev at masklinn.net
Sat Apr 16 18:45:34 CEST 2011

On 2011-04-16, at 17:25 , Antoine Pitrou wrote:

Le samedi 16 avril 2011 à 17:07 +0200, Xavier Morel a écrit :

On 2011-04-16, at 16:52 , Antoine Pitrou wrote:

Le samedi 16 avril 2011 à 16:42 +0200, Dirkjan Ochtman a écrit :

On Sat, Apr 16, 2011 at 16:19, Antoine Pitrou <solipsis at pitrou.net> wrote:

What you're proposing doesn't address the question of who is going to do the ongoing maintenance. Bob apparently isn't interested in maintaining stdlib code, and python-dev members aren't interested in maintaining simplejson (assuming it would be at all possible). Since both groups of people want to work on separate codebases, I don't see how sharing a single codebase would be possible.

From reading this thread, it seems to me like the proposal is that Bob maintains a simplejson for both 2.x and 3.x and that the current stdlib json is replaced by a (trivially changed) version of simplejson. The thing is, we want to bring our own changes to the json module and its tests (and have already done so, although some have been backported to simplejson). Depending on what those changes are, would it not be possible to apply the vast majority of them to simplejson itself? Sure, but the thing is, I don't think we are interested in backporting stuff to simplejson much more than Bob is interested in porting stuff to the json module. I was mostly thinking it could work the other way around, really: simplejson seems to move slightly faster than the stdlib's json (though it's not a high-churn module either these days), so improvements (from Python and third parties alike) could be applied there first and then forward-ported, rather than the other way around.

I've contributed a couple of patches myself after they were integrated to CPython (they are part of the performance improvements Bob is talking about), but that was exceptional. Backporting a patch to another project with a different directory structure, a slightly different code, etc. is tedious and not very rewarding for us Python core developers, while we could do other work on our limited free time. Sure, I can understand that, but wouldn't it be easier if the two versions were kept in better sync (mostly removing the "slightly different code" part)?

Furthermore, now that python uses Mercurial, it should be possible (or even easy) to use a versioned queue (via MQ) for the trivial adaptation, and the temporary alterations (things which will likely be merged back into simplejson but are not yet, stuff like that) should it not? Perhaps, perhaps not. That would require someone motivated to put it in place, ensure that it doesn't get in the way, document it, etc. Honestly, I don't think maintaining a single stdlib module should require such an amount of logistics.

I don't think mercurial queues really amount to logistic, it takes a bit of learning but fundamentally they're not much work, and make synchronization with upstream packages much easier. Which would (I believe) benefit both projects and — ultimately — language users by avoiding too extreme differences (on both API/features and performances).

I'm thinking of a relation along the lines of Michael Foord's unittest2 (except maybe inverted, in that unittest2 is a backport of a next version's unittest)

More information about the Python-Dev mailing list