Guido wrote:
I think a fair amount of our time and work is better spent on the stdlib, various implementation(s) and things of that nature (ecosystem).
Of course, no moratorium can stop people from *proposing* changes, but it helps core developers and others who "just want to get stuff done" focus if they know we're not changing the language for quite a while.
Effectively the moratorium would freeze the language at the 3.1 version at least for 3.2 and possibly for 3.3. Also 2.7 could not add language changes except possibly changes to keep up with 3.1 (but only if *very* strict backwards compatibility with 2.6 is maintained also -- I want the upgrade from 2.6 to 2.7 to be a breeze for everyone).
Obviously there are many things we could change in the standard library that would still affect the ability to upgrade easily (see the recent issues with 2.6.3 and 2.6.4), and we should be exercising a lot of restraint in this are as well. But language changes affect other implementations the most (I think). They also coincidentally speak most to the imagination of the young, eager-to-add-their-pet-feature amateur language designer crowd who so often fill python-ideas with heated discussions.
This generally sounds nice for us and will make it easier to catch up to 3.x as well as make it easier to continue to flush out other missing built-in modules. But I would actually be really happy with just a partial freeze though - I actually find support for new standard library features is typically the biggest hit for us and that core language features (modulo import related features which are always difficult ) have generally not been an issue. For example consider multiprocessing - which IronPython still doesn't support. That's a much bigger work item than everything that changed related to parsing in 2.6. New built-in functions can also be a huge pain - again compare float.fromhex to everything that happened to the parser in 2.6. I'm pretty sure I spent more time on float.fromhex even w/ the already existing awesome test suite. So I definitely think not adding significant new functionality to the core interpreter would be great but from an alternate implementation perspective I'd also be happy to see some wiggle room on small new features.