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

[geremy condra]

On Sat, Oct 24, 2009 at 1:30 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> geremy condra writes:
>
>  > Didn't say it was a democracy. Assumed that it would still involve
>  > some input from its user base. Is that wrong?
>
> Your phrase "popularly supported" is ambiguous.  If you mean "attracts
> widespread support in the form of description of varied and plausible
> use cases" for new syntax and built-ins, or something like that, I'm
> sure the answer is "yes".  The question posed by the moratorium
> proposal is, "When?"
>
> It seems to me that what Guido is heading for here is very similar to
> the "punctuated equilibrium" concept (associated with the evolutionary
> biologist Stephen Jay Gould, the wikipedia article is pretty good, and
> fairly short).  The basic idea is that long periods of relative
> stability are "punctuated" by periods of rapid evolution.  In biology,
> the "bleeding edge" involves literal deaths, and Nature doesn't
> hesitate to waste large percentages of a population over the "stable"
> period as well as decimating it during the rapid evolution phases.
>
> In software, it may make sense to have the stable periods be *much*
> more stable, since artificial systems are more fragile than natural
> ones.  C, because it occupies an "ecological niche" as a high-level
> assembly language, has been quite static since its original
> definition, even when it evolves.  Python need not be, since its niche
> is very different.  But it makes sense to propose to compress the
> evolution into short periods with many changes, and have very stable
> periods of "moratorium" between.  Whether it will work well or not,
> we'll have to try it to see.  But it's not just Guido's intuition that
> says it will work to the advantage of Python.
>
>

Let's just clear up a misconception: I am *for a moratorium*.
As in, +1 from me.

Having said that, I do not agree that development on
changes to the language should stop, just that it should
stop being integrated until we've had a long breather,
allowed the other implementations to catch up to
some degree, and given ourselves time to assess
what the actual state of the language is post-2.x.

The problem is that once we're out of the moratorium
we'll be back in the same situation: every change will
put the other implementors behind the one with the
most man-hours to devote to it, we still won't know
how any two changes to the language will interact,
and we still won't be able to reasonably and
empirically evaluate the worth of any particular
proposed feature. We'd need another moratorium
straight off.

My solution to this problem is a simple one: create
a sandbox where we can leverage Mercurial's ability
to create cheap and easy branches to get a glimpse
of possible future Pythons. We allow people to keep
coming up with ideas and keep developing ideas on
the off chance that one of them works so well that
we want to integrate it after the moratorium lifts.
There is no obligation here, no demands made on
anyone's time who does not care to take a look
at whats happening in the sandbox. In a few words,
there is no cost.

If done properly this will give both the CPython
user base and the other implementors a period
of not weeks but months or years to evaluate a
proposed change to the language; it will force
those proposing such changes to actually come up
with code to match them, sparing the core devs
time that could be better spent on the libraries or
on improving Python 3 support in the community;
it might even help thin out the requests for those
features that are likely to be rejected, since
seeing that an implementation has been rejected
is frequently more compelling than hearing that
a similar proposal has been dismissed in the
past.

As I say, it seems like a good idea to me, and
if it turns out later not to have been it has
virtually no consequences. Others will doubtless
have different opinions.

Geremy Condra