On Sat, Oct 24, 2009 at 1:30 AM, Stephen J. Turnbull <stephen@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