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

[Nick Coghlan]

Bruce Frederiksen wrote:
> OK, I'm an outsider here.  But looking at this whole discussion a
> picture emerges.  So I'll toss this out here for discussion (and I'm
> really going out on a limb here, but it's OK to shoot the outsider!)
> 
> "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..."
> 
> What I see happening is a realization as we move into 2010 that the C
> language is no longer the future.  We may not know yet what language is
> the future.  And we might imagine that it ought to be Python.  This
> discussion is being done within the CPython group.  That has two parts:
> C and Python.  I see the moratorium as a declaration that Python needs a
> new implementation.  It needs a new horse to ride on.

I don't believe this is an accurate characterisation of the situation
(neither in regards to the state of C, nor in regards to the state of
Python).

C isn't going anywhere - it is still massively important as a portable
language that can be made to run pretty much anywhere with minimal
application overhead relative to raw assembler (and often faster than
hand-coded assembler, since humans aren't smart enough to manually
optimise code for many modern processors). Developers of new platforms
don't need to tediously hand code lots of tools - they just need to
teach a C compiler to generate code for their platform and the
bootstrapping process gets off to a flying start.

However, C retains that relevance without the core language changing
very much - the last major update was C99, and the update before that
was C89, which was itself a consolidation of assorted features
introduced by various alternative implementations since K&R C was
documented in 1978. Some would even say that it is the very simplicity
and stability of C that has lead to its ubiquity.

So that's 2 language updates in more than 30 years since a C language
spec was first articulated. Python has had more major updates than that
in barely half the time. Now, for a long time, that didn't really matter
because only the reference interpreter saw serious use. Stackless was
around, but able to pick up most changes directly from the reference
implementation (since it only modified the VM and was able to retain
most of the rest of the core C code), while Jython fell by the wayside
for a while when new style objects were introduced in Python 2.2.

The situation now is significantly different. There are at least 3 major
Python implementations under active development and in production use
that I know of (CPython, Jython, IronPython), other major
implementations that, if not in production use yet, will be eventually
(e.g. PyPy, Unladen Swallow) and various other tools based around
existing Python syntax (Pyrex, Cython).

Changes to the core language spec now affect a *lot* more than just
CPython - there are ripple effects that spread out through the whole
language ecosystem. On the other hand, standard library changes to
modules that other Python implementations are able to use without
modification don't generally have anywhere near the same impact.

Guido's proposed moratorium is a formal recognition of the fact that
tinkering with the underlying language isn't what Python really needs
right now. It *is* possible for a language to become "feature complete"
from a practical point of view, after which tinkering at the edges and
introducing special syntax for niche use cases becomes a distraction
from more productive endeavours.

We changed a lot of things in Py3k - by saying "no, we aren't going to
change anything else in the core language spec for at least the next few
years" we would be consciously taking a step back and waiting to see how
all those changes play out in the real world before we start trying to
build on them.

We would be giving the alternative implementations a chance to come up
to speed with their own Python 3.x implementations, giving major
applications and frameworks a chance to do forward ports without
difficult decisions as to which version to target and giving users a
chance to get used to a new feature set before throwing yet more deltas
at them (e.g. I don't think anyone has even begun to scratch the surface
of the power and flexibility provided by PEP 3115).

Are language changes going to be completely impossible under such a
moratorium? Of course they aren't - if a solid enough case is made for a
change, then we aren't going to dig our heels in just because we made a
formal statement that we didn't want to change certain things for the
next few years. If somebody comes up with a language improvement that is
as groundbreaking as the with statement was for Python, or as
asynchronous blocks would be for C, then of course we would still give
it serious consideration.

However, even a cursory glance at Python ideas shows that most current
suggestions for tweaks to the core language don't really measure up to
that standard. Even PEP 380 (generator delegation), which is a decent,
well thought out suggestion, has to rely fairly heavily on language
consistency and coherency arguments because the real world use cases
that can't already be handled a different way are fairly minimal.

Thanks for posting what you did though - while I believe your perception
of the situation is incorrect, it helped crystalise in my mind *why* I
think Guido's suggestion is a good idea. Previously I hadn't posted
anything, as I wasn't sure whether or not I agreed with the concept.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------