On Fri, Oct 23, 2009 at 11:45 AM, Nick Coghlan <ncoghlan@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