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

[Guido van Rossum]

On Wed, Oct 21, 2009 at 11:26 AM, Raymond Hettinger <python at rcn.com> wrote:
> [Guido van Rossum]
>> Note, the moratorium would only cover the language itself plus
>> built-in functions, not the standard library.
>
> That makes sense.
>
> There may be a few areas that still have some rough edges where you
> may want to allow changes if needed (tweaks to the nested with-statement
> syntax, bytes/text interaction, star-args unpacking, or string formatting).
> These areas probably have not been exercised much and there may still be
> problems that need to be ironed-out.  I don't have anything specific
> in mind.  Am just thinking that those features aren't yet mature.

No, the moratorium would freeze the language at the 3.1 version, at
least for 3.2 and 2.7 and possibly 3.3 (see my earlier post). Allowing
for exceptions like these provides too much wiggle room. (E.g is the
decorator syntax broken?)

Outright bugs in the implementation should be excepted (subject to
discussion) but the accepted grammar and semantics should be frozen
unless they are unimplementable.

> Also, do you know if there any plans afoot to do something with function annotations?

I don't. Giving them more semantics would fall under the moratorium;
however some implementations might have optional extensions that
don't. I can also see that implementations which support interaction
with APIs defined in other languages (chiefly IronPython and Jython)
might define semantics for function annotation syntax in certain cases
where it benefits interaction with other languages -- this would be in
code that is naturally restricted to that implementation anyway.

>>  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.
>
> FWIW, I have pending updates for the set/frozenset implementation
> (no api change).

If it's just performance that's fine. If there's more I'd like to hear
more details first.

> Also, I'm hoping the recently submitted C implementation for decimal
> gets accepted (as performance issues seem to be slowing broader
> use of the module).  It looks like substantial work has already
> been done.

I don't think that "work on a feature has already begun" should be an
argument for granting an exception. However I expect that in this
specific case this falls under the library, which is not directly
covered by the moratorium. I think I saw that it could be made
optional, so that if the C implementation isn't found the Python
implementation still works?

>> 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.)
>
> Are you rejecting PEP 380?

No, just deferring it. It didn't make Python 3.1 so I think we'll have
to live without it for a long time no matter what. It could be
revisited once the moratorium is lifted (for 3.3 or 3.4).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)