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 <solip...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
