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@gmail.com | Brisbane, Australia ---------------------------------------------------------------