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

[Georg Brandl]

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.