[Python-ideas] Proposal: Moratorium on Python language changes

[Brett Cannon]

On Wed, Oct 21, 2009 at 09:42, Guido van Rossum <guido at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20091021/13058af1/attachment.html>