Brett Cannon schrieb:
I propose a moratorium on language changes. This would be a period of several years during which no changes to Python's grammar or language semantics will be accepted. The reason is that frequent changes to the language cause pain for implementors of alternate implementations (Jython, IronPython, PyPy, and others probably already in the wings) at little or no benefit to the average user (who won't see the changes for years to come and might not be in a position to upgrade to the latest version for years after).
+1 from me. In this rather long thread someone proposed allowing changes that make implementation of the language easier, which I am also fine with, but that could almost be classified a bug fix and taken on a case-by-case basis. But completely new exposed syntax or semantics for the language and built-ins should be off limits.
And for the "several years", I say make through 3.4, letting in new features for Python 3.5 which should be open for development in mid 2013.
That's a looong time (for me at least), but still an acceptable timeframe.
The main goal of the Python development community at this point should be to get widespread acceptance of Python 3000. There is tons of work to be done before we can be comfortable about Python 3.x, mostly in creating solid ports of those 3rd party libraries that must be ported to Py3k before other libraries and applications can be ported. (Other work related to Py3k acceptance might be tools to help porting, tools to help maintaining multiple versions of a codebase, documentation about porting to Python 3, and so on. Also, work like that going on in the distutils-sig is very relevant.)
The moratorium should also give us time and space to focus on bug fixes for the language which is good.
Do you really think so, or do you say it because you wish it was true? The occasional syntax change doesn't block many developer resources. IMO it's the tedious interminable discussions on library and infrastructure issues, e.g. distribution/packaging or the future of WSGI, and none of these is going to be cut off or settled.
But the moratorium would clearly apply to proposals for anonymous blocks, "yield from" (PEP 380), changes to decorator syntax, and the like. (I'm sure it won't stop *discussion* of those proposals, and that's not the purpose of the moratorium; but at least it will stop worries elsewhere that such proposals might actually be *accepted* any time soon.)
Sounds good to me. While I heard some people on Twitter want PEP 380, if we are going to freeze it should be across the board. I can see someone arguing that at least PEP 380 is in a PEP format, but even then that doesn't mean its fully thought out (and I am not explicitly talking about PEP 380 as I have not read it in ages).
A side benefit to this is it will give us time to come up with a PEP that clearly defines exactly what is required to propose and get accepted changes to the language (I also want to do this for the standard library, but I view that as a different PEP). Hopefully that will cut down on the wild proposal on python-ideas and give people a much clearer idea of what is required of them. As I view this as a developer doc thing I am willing to write these PEPs (eventually =).
One thing I would like to see happen for this moratorium is us following a more rigid release schedule in terms of feature freeze. So I would propose that starting with 3.2 we feature freeze 18 months after 3.2's feature freeze. Now I am not suggesting we lock down the final release date to 18 months as who knows how long it would take to shake out the bugs, but we can easily say that every 18 months we feature freeze for the next minor release (major releases don't apply to this schedule and I am not worrying about micro releases as that is not under discussion here).
+1 for predictable release schedules. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.