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

geremy condra debatem1 at gmail.com
Fri Oct 23 06:52:11 CEST 2009


On Wed, Oct 21, 2009 at 4:24 PM, Brett Cannon <brett at python.org> wrote:
>
>
> 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 =).

I second this- especially if it includes a code-first requirement.

> 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).

Ditto.

> 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

Sounds good to me.

Geremy Condra



More information about the Python-ideas mailing list