Guido van Rossum wrote:
On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <debatem1@gmail.com> wrote:
Towards that end, I'd also like to propose a very public, very accessible 'sandbox' specifically for the development and testing of new language features while the moratorium is in effect. Its goal would be to keep interest in changes to core language design ongoing by keeping the barrier to entry low, while simultaneously separating it from core development. With any luck, it would mean that when the moratorium lifts, Python will be able to take its pick from the best of the language proposals, while still having given other implementations the opportunity to study their behavior "in the wild" for a period of months or years.
I can't stop people from forking the language to do experiments, but one of the goals I have for the moratorium is actually to *reduce* the interest in core language changes, and to *raise* the barrier to entry. Most language change proposals are just fluff, and they will be just as unneeded three years from now as they are today. Once the moratorium is lifted, users should be able expect the normal, slow, conservative evolution of the language to continue -- not to see the floodgates lifted for a barrage of new features.
Here's a thought: How about directing the developement effort in a predictable pattern. An example of this might be... 3.2 - library development, and bugs 3.3 - bug fix's only, (long term stable release) 3.4 - core development, bugs 3.5 - library, bugs 3.6 - bugs only, (long term stable release) 3.7 - core, bugs 3.8 - library, bugs 3.9 - bugs only, (long term stable release) Also one of the things I like about Ubuntu's development, is the pre announcement of what areas of Ubuntu will be worked on. I think that has a really good effect on how well development efforts are focused. Cheers, Ron Adam