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

[Steven D'Aprano]

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

http://archive.adaic.com/docs/reports/lawlis/k.htm


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:

http://www.jython.org/archive/22/news.html

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


[...]
> 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 
modules are.

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.




-- 
Steven D'Aprano