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

[geremy condra]

On Mon, Oct 26, 2009 at 2:12 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> geremy condra writes:
>
>  > There is an enormous risk that they are wasting their time.  The
>  > goal [of a sandbox] is to save the core devs' time, not those
>  > proposing features.
>
> The core devs' time will be saved by ignoring the sandbox (other than
> their own features),

Until a feature because quite mature, yes- afterwards, no. That's
the point of keeping it separate.

> and if it intrudes on them (eg, in the commit
> notices), they will request that it forcibly be shut up.  Cf. the
> short exchange you had with Nick on the subject of commit notices.
>

I've already addressed that, see the messages you reference.

> ISTM that rather the goal is to ensure that features that would
> otherwise be overlooked or be blocked because the proponent is
> unwilling to follow through to the extent required (ie, by a new
> proposal at the time of ending the moratorium) be given more
> consideration.

Nope, not the goal.

> I don't think a sandbox will help with that, unless it
> is designed to give incentives and help in producing *better*
> proposals.  Just collecting them in one place is not going to help.
>

No, it wouldn't. Because that's not the point.

>  > > It would.  But consider the PEP for ipaddr.
>  >
>  > I honestly don't see what this has to do with this proposal.
>
> It's a common pattern of discussion, for both stdlib and core
> syntax/builtins, and I chose it because it was close to the boundary
> of approval.  I didn't want to choose nonstarters like multiline
> blocks or trivial suggestions like a warning for "breakless for-else".
>
>  > 2) the situation was complicated by recriminations about
>  > the openness of python, the role of the mailinglists vs
>  > the bugtracker, and numerous other issues that we don't
>  > need to go into here.
>
> Are you sure you're not confusing it with the distutils thread(s)?
>

Pretty sure.

>  > 3) According to people who know a great deal more about
>  > netmasks than I ever will, the things the author was
>  > unaware of would fill several large books, and even Guido
>  > repeatedly emphasized his lack of knowledge on the subject.
>  > By contrast, the group of core Python developers is
>  > uniquely qualified to talk about changes to the language's
>  > syntax and behavior.
>
> But those are precisely the people whose time you plan to save.

Yes it is.

>  The only way to save their time is to do less reviewing.

Nope, pretty sure that coming in to do a code review at the
end is less time consuming than being involved with a
feature from the beginning.

> Having an official sandbox might do that by giving the dross a
> place to collect, so the core devs *never* look at it.<wink>

I like to think that the fact that a patch comes from outside
of core will not impact its consideration by that group.

>  > We're talking about changes to the core language. I would suggest
>  > that the only "apps" possible under those conditions would be
>  > extensive test suites and real-life use.
>
> Yup.  Precisely the kind of stuff that happens in real projects, not
> in sandboxes.

True, and irrelevant. The sandbox I propose is not the existing
python sandbox. Choose a different term for it if you want,
but anything in it that wants acceptance had better be damned
good, and that, in my mind, includes thorough testing.

>  > > There will be way too many of them to be reviewed at all, let alone
>  > > easily, if all people have to do is post a branch to an official
>  > > sandbox.
>  >
>  > I doubt this. Experience suggests that the number of individuals
>  > proposing changes with the technical chops to pull them off is
>  > relatively small,
>
> Sure, but they generally also are core developers.  I don't see why an
> "official sandbox" will be of use to them.

Some core devs may decide to use it to produce features that
aren't going to come in under the moratorium, but people outside
the core dev group can also use it. Don't assume that the only
people with the experience and knowledge to implement such
a change are part of the core dev group- especially a couple of
years from now.

Geremy Condra