[Python-ideas] Proposal: Moratorium on Python language changes

[geremy condra]

On Sun, Oct 25, 2009 at 3:01 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> geremy condra wrote:
>> On Sun, Oct 25, 2009 at 1:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> I'm a little unclear on what you're driving at here-
>> my goal is to keep these projects off the minds
>> of the core devs until they're about ready to go, to
>> make it easy for all the implementors to carefully
>> assess both the features themselves and the
>> code used to implement them as they near that
>> point, and to make certain that there is a common
>> point of reference for the debate over inclusion
>> afterwards. In other words, not specifically to
>> remove python-dev from the process, but rather
>> to allow it to spend its time more productively
>> elsewhere until it can be usefully spent there.
>
> Having an "official sandbox" is completely irrelevant (and probably
> counterproductive) if core development is happening in a DVCS.

I don't see any evidence for either of these claims, and IMO the
argument that somehow allowing people to "go play over there"
until they've got something that could seriously be considered for
merging is going to slow down core development is a little silly.

>If people
> want to experiment, they will be able to experiment by branching into
> their own repository. Trying to create an "official sandbox" (or, more
> likely, use the existing sandbox) defeats the whole point of the
> exercise, since it just brings the CPython admins back into the loop and
> will generate a pile of irrelevant traffic on python-checkins.
>

I don't see the sandbox working this way. I see it being somewhat
more separated from the official core, probably to the point where
it wouldn't generate checkin messages and hopefully to the point
where it wouldn't require a dev to start a publicly viewable branch.
This also avoids the problem of having to go through a kajillion
different places to see what kinds of proposals have active support
or are close to completion and which aren't, which should help
to discourage people from duplicating effort, as well as giving the
various implementors more advance warning on what might be
coming down the pipe.

> In short, a moratorium that said "we won't accept things into trunk, but
> you can still pester us to add things to our official sandbox" would be
> a pointless exercise.
>

You see the difficulty of occasionally reviewing a substantive,
testable proposal for a language change as being enough to
outweigh the advantages Guido has attributed to the moratorium?
And here I was thinking that adopting a code-first-jaw-later
approach would save the devs time.

> Moving to a DVCS, putting a core language change moratorium in place for
> a few years, then looking to see what improvements have been developed
> outside the core tree as the moratorium is running down (and what
> feedback has been received over that time) would be far more sensible.
>

That's the goal, I'd just also like to have all those improvements
centralized for easy review and comparison.

Geremy Condra