On Wed, Oct 21, 2009 at 09:42, Guido van Rossum
<guido@python.org> wrote:
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.
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.
Note, the moratorium would only cover the language itself plus
built-in functions, not the standard library. Development in the
standard library is valuable and much less likely to be a stumbling
block for alternate language implementations. I also want to exclude
details of the CPython implementation, including the C API from being
completely frozen -- for example, if someone came up with (otherwise
acceptable) changes to get rid of the GIL I wouldn't object.
Sounds reasonable to me.
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).
This would give us and the community a much clearer indication of when the moratorium will be lifted. So we could say that 3.2 is feature frozen on June 15, 2010, Python 3.3 on January 15, 2012, and Python 3.4 on June 15, 2013. We can obviously choose some other set of dates (went with this to avoid releasing on New Years, although it might be fun to shift to Oct 5 as that's the date Flying Circus was first broadcast), but it would be nice to be able to say that "after Python 3.4, which is feature frozen on XXX, we will start looking at new features again for Python 3.5".
-Brett