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

[Stephen J. Turnbull]

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), 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.

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.  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.

 > > 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)?

 > 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.  The
only way to save their time is to do less reviewing.  Having an
official sandbox might do that by giving the dross a place to collect,
so the core devs *never* look at it.<wink>

 > 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.

 > > 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.