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

[geremy condra]

On Sun, Oct 25, 2009 at 11:28 PM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> 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.
>

Hadn't thought of that. I'd prefer that there be a hosting facility
involved, but it's a long way from being critical- assuming the
other objections to the sandbox could be settled, this would get
a +1 from me.

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

There is an enormous risk that they are wasting their time.
The goal is to save the core devs' time, not those proposing
features.

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

I don't envision this ever reaching the scale of the kernel, and if
you feel there is any risk of it doing so then I suggest we implement
it ASAP, since there are evidently thousands of heretofore unseen
core developers with a curious aversion to centralized version
control systems.

>  > 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 honestly don't see what this has to do with this proposal.

1) ipaddr made no effort to change the language itself, and
would in any event be eligible for consideration under the
normal rules during the course of the moratorium.

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. That such a wide-ranging discussion
would cause consternation should surprise no one.

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.

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

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. Realistically, we can only
have the former without large-scale acceptance of a program
similar to, but larger in scope than, the one I am proposing.

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

I doubt this. Experience suggests that the number of individuals
proposing changes with the technical chops to pull them off is
relatively small, and my own admittedly limited familiarity with
human nature leads me to conclude that the formidable
obstacles piled along the road to acceptance will discourage
all but the most determined proposals.

Geremy Condra