[Python-ideas] Proposal: Moratorium on Python language changes
steve at pearwood.info
Sat Oct 24 05:52:47 CEST 2009
On Sat, 24 Oct 2009 02:45:18 am Nick Coghlan wrote:
> 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.
In other words, there were various (I'd say "many") incompatible
implementations of C that introduced their own core changes over the
years, and eventually the C standard caught up with what those
implementations had already done. And the process continues: google
on "non-standard C" for examples. E.g.:
"C has followed the standardization path of most languages. First, the
language was created and used. As its popularity grew, it began to
spawn a number of different dialects. Then, C went through a
standardization process, with the main core of the language being
standardized. It is common for compiler implementations to support
standard C with additional, system-dependent features. This results in
the creation of much non-standard C code."
"C is standardized by both ANSI and ISO. However, there is no reasonable
expectation that a C compiler will follow the standard without
including additional features."
That's hardly the same as saying that C was unchanging or that there was
a moratorium on changes to the language. That's more like the language
continued to evolve, in mutually inconsistent directions, and it was
merely the standard that was out of touch with the practice of C across
various incompatible implementations.
There's plenty of working non-standard C code in the world. I'm not sure
that it's even possible to write non-standard Python code. There are,
naturally, libraries that only exist for one platform or one
implementation, but that's not the same thing.
> 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.
"Fell by the wayside"? Are you saying that the popularity of Jython
*declined* because of the introduction of newstyle classes in CPython?
I have an alternative interpretation. Jython 2.2 (equivalent to CPython
2.2, including new-style classes) was finally released in August 2007,
a year after CPython had released 2.5. This was Jython's first
production release in six years:
If so, that suggests to me that Jython developers abandoned Jython
(probably for CPython) because they thought Jython was moribund. They
voted with their feet in favour of an implementation with regular and
useful changes to the core over an implementation which was stable and
> 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.
We keep being told this, but so far only one developer of an alternative
implementation has spoken up. According to IronPython's Dino Viehland,
language features are rarely a problem for him, but some library
I would really like to hear from some other implementation developers.
I'd also like to hear from the maintainers of large Python projects or
libraries -- why aren't they migrating to 3.1? Is it because they fear
3.2 will include new core features? I can't imagine this is a problem,
because if they're supporting 3.1, they have to use the features in 3.1
and not those in 3.2 -- whether those features are in the core or the
library. Adding features to newer versions can't hurt them, although
obviously changing or removing features will. But Python is already
conservative about changing and removing features, so a moratorium
doesn't change that.
> 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.
Perhaps so, but many of the changes being suggested are better described
as "filing off the rough edges". Not every new feature has to be as big
a change as the introduction of while, or decorators. Small changes
which are easy to implement can make a big difference to usability to.
More information about the Python-ideas