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

[Stephen J. Turnbull]

geremy condra writes:

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

Given the degree of decoupling you describe, there's no need for
Python to host anything more than a simple CGI for registering remote
branches.  Probably for the purpose we have in mind the CGI should
check that it actually *is* a branch of an official Python branch.

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

It's a waste of their effort to "play over there" in hopes that their
feature will ever be considered.  If it's small enough to be
considered and approved without a major use case, it probably can be
maintained as a patch on the tracker indefinitely.

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

This is a chunk of management effort to do properly.  Take a look at
git.kernel.org and tell me which of those branches matter, and to whom.
Unless you're a kernel activist, I bet you cannot.

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

It would.  But consider the PEP for ipaddr.  That discussion was a
total waste of everybody's time because the proponent never put
forward a use case in working code for the most controversial feature,
making it impossible for anyone to figure out WTF he was thinking.  It
turns out he wasn't thinking about anything at all, the "feature" was
merely an artifact of his implementation, and he didn't understand
what others were talking about.  When he finally did get around to
thinking about what they were talking about, he immediately accepted a
sensible proposal, the compromise was accepted with some grumbling,
and work can proceed.

I forsee lots and lots of those if the only code to review is the
implementation of the feature in the officious sandbox.  Much better
if we can look at the big picture in the context of a real app
developed wa-a-ay over there, and a sub-repo containing the relevant
branch of Python core.  Since it *is* a branch of Python core, you
just clone the core, and do "hg merge" and you've got a reviewable
implementation.

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

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.