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

[geremy condra]

On Fri, Oct 23, 2009 at 11:45 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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).
>

Agreed.

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

Importantly, while Python is not Java, Python is also not C.
The analogy between Python's life cycle and that of a language
that was designed entirely in-house and before the words
"internet" or "open source" were coined is at best flawed and
at worst dangerously misleading. I would point instead to the
development of a language like PHP as the more accurate
metaphor- and despite its syntax and core language changes,
it remains more popular than Python.

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

Granted, and this is why I support the moratorium. However,
I also support eventually *lifting* the moratorium- Python
competes more against today's highly dynamic languages
than yesterday's quite static languages. Stand too still for
too long and we risk standing nowhere at all.

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

And I agree that it isn't what Python needs *right now*. But that
is totally different from saying that there simply aren't any good
ideas left. We should give those ideas an opportunity to be
heard so that in a few years when everybody is caught up we
stand in a position to make good, well-informed decisions
about what the language needs.

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

Agreed.

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

Agreed.

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

Actually, that's almost exactly the opposite of what Guido said- that there
will be no one-change exceptions.

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

Arguments against past proposals are not arguments against
future proposals. Unless Guido's time machine got an extra
supercollider while I wasn't looking, nobody on this board knows
what's coming down the pipe next, and my argument is that if
the suggestion is super-awesome, popularly supported, and
maintained until the end of the moratorium, then it should have
a really good chance of getting in. To paraphrase a discussion
I had on this topic last night, the fact that there's a long, hard
road to getting a feature into the language isn't a problem. The
idea that there shouldn't be a road is.

Geremy Condra