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

[Xavier Morel]

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)