Proposal: Moratorium on Python language changes

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 (Jython, IronPython, PyPy, and others probably already in the wings) at little or no benefit to the average user (who won't see the changes for years to come and might not be in a position to upgrade to the latest version for years after). The main goal of the Python development community at this point should be to get widespread acceptance of Python 3000. There is tons of work to be done before we can be comfortable about Python 3.x, mostly in creating solid ports of those 3rd party libraries that must be ported to Py3k before other libraries and applications can be ported. (Other work related to Py3k acceptance might be tools to help porting, tools to help maintaining multiple versions of a codebase, documentation about porting to Python 3, and so on. Also, work like that going on in the distutils-sig is very relevant.) Note, the moratorium would only cover the language itself plus built-in functions, not the standard library. Development in the standard library is valuable and much less likely to be a stumbling block for alternate language implementations. I also want to exclude details of the CPython implementation, including the C API from being completely frozen -- for example, if someone came up with (otherwise acceptable) changes to get rid of the GIL I wouldn't object. But the moratorium would clearly apply to proposals for anonymous blocks, "yield from" (PEP 380), changes to decorator syntax, and the like. (I'm sure it won't stop *discussion* of those proposals, and that's not the purpose of the moratorium; but at least it will stop worries elsewhere that such proposals might actually be *accepted* any time soon.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
As one of the lead developers of the Cython project, which is following CPython at some distance but at fast pace (and high speed ;), I honestly wouldn't mind such a moratorium. As a Python language user, I must say that I cannot remember any recent(?) language syntax proposal on python-ideas that would have made the language substantially better. Plus, a lot of the code that gets written even today is still required to stay Py2.x compatible, sometimes as old as 2.3. Especially library or tooling code will often not even use Python 2.6 features for a while, let alone Python 3.x features. That doesn't mean you can't 2to3 it, it just means that it won't use the new syntax features. I guess that makes a +1 from my side. Stefan

Stefan Behnel wrote:
Dito! The last useful (and today widely used) syntax change in the 2.x series was the 'with' statement. I don't see urgent need for any syntax or language chances in the next couple of year. The only new feature I can think of, that might require new syntax, is parallel processing and executing multithreaded, GIL-less code. Such a feature is going to take a long time before it's implemented. I'm +1 on your proposal, Guido. Do you propose a fixed time span for the moratorium or a status quo? Can we continue changing the language once Jython and IronPython have fully implemented Python 2.7 / 3.2? Christian

On Wed, Oct 21, 2009 at 10:43 AM, Jesse Noller <jnoller@gmail.com> wrote:
+1; modulo getting PEP 380 in before the moratorium ;)
I see the smiley, but just in case you were half serious, I really think we should stick to the policy and not make exceptions for personal pet peeves.
Of course, no moratorium can stop people from *proposing* changes, but it helps core developers and others who "just want to get stuff done" focus if they know we're not changing the language for quite a while. Effectively the moratorium would freeze the language at the 3.1 version at least for 3.2 and possibly for 3.3. Also 2.7 could not add language changes except possibly changes to keep up with 3.1 (but only if *very* strict backwards compatibility with 2.6 is maintained also -- I want the upgrade from 2.6 to 2.7 to be a breeze for everyone). Obviously there are many things we could change in the standard library that would still affect the ability to upgrade easily (see the recent issues with 2.6.3 and 2.6.4), and we should be exercising a lot of restraint in this are as well. But language changes affect other implementations the most (I think). They also coincidentally speak most to the imagination of the young, eager-to-add-their-pet-feature amateur language designer crowd who so often fill python-ideas with heated discussions. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 2:06 PM, Guido van Rossum <guido@python.org> wrote:
The only reason I would argue against that would be for the fact that AFAIK, it's "nearly done and ready" - that being said, that is a specious argument. But I agree - no exceptions makes sense.
Agreed; there's been discussion on disutils-sig and other places (such as the language summit) revolving around a "single, shared" standard library for all of the implementations. So long as the syntax is unchanged, we can upgrade/improve the stdlib over time, and make it used for the various implementations. jesse

Guido van Rossum schrieb:
Well, the moratorium isn't yet in place (which I also gather from you posting that on the ideas list), so would be nothing wrong implementing something before it starts... :) Anyway, I'm not sure how much impact this will have; already there are very few real language changes going on; after 2.6, whose such changes mostly were Python 3 backports. In 2.7, the multi-with syntax is the only real language change so far. (When you say "builtins", do you e.g. include the str.format() mini-language? There has been a lot of work on that lately, to fix ambiguous corner-cases.) I'm not saying it's a bad idea, but while it might stop a few threads on python-dev, it won't change a lot in terms of how core development time is spent. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Wed, Oct 21, 2009 at 11:24 AM, Georg Brandl <g.brandl@gmx.net> wrote:
No, the moratorium would freeze the language at the version implemented in 3.1. If necessary we'd have to roll back core language changes (primarily syntax, or new builtins) made since 3.1 was released.
I think fixing ambiguous corner cases can proceed.
My main goal is to set expectations right -- people who spend effort porting to 3.1 should not be confronted with further effort caused by the upgrade to 3.2. (An alternative would be to postpone the release of 3.2 until the moratorium is over, but this would unnecessarily constrain further development of the library.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido wrote:
This generally sounds nice for us and will make it easier to catch up to 3.x as well as make it easier to continue to flush out other missing built-in modules. But I would actually be really happy with just a partial freeze though - I actually find support for new standard library features is typically the biggest hit for us and that core language features (modulo import related features which are always difficult ) have generally not been an issue. For example consider multiprocessing - which IronPython still doesn't support. That's a much bigger work item than everything that changed related to parsing in 2.6. New built-in functions can also be a huge pain - again compare float.fromhex to everything that happened to the parser in 2.6. I'm pretty sure I spent more time on float.fromhex even w/ the already existing awesome test suite. So I definitely think not adding significant new functionality to the core interpreter would be great but from an alternate implementation perspective I'd also be happy to see some wiggle room on small new features.

On Wed, Oct 21, 2009 at 3:07 PM, Dino Viehland <dinov@microsoft.com> wrote:
I don't think IronPython should support multiprocessing, personally. While there are a few things within it that probably make sense (managers and the like) does it really make a ton of sense to run multiple iron python VMs from a single parent? The same applies (in the case of multiprocessing) to Jython - a single JVM forking multiple JVMs doesn't necessarily make sense when you have perfectly functional threads. Then again, this depends on your perspective. When splitting out the stdlib was discussed at the language summit last year, this was discussed, and at the time a few people suggested allowing some stdlib modules to be marked at "cpython-only" - this means other implementations could omit/skip those modules (and not ship them). jesse

Jesse wrote:
The problem w/ this is that people are going to use multiprocessing and then someone is going to try running code which uses it on IronPython/Jython and it isn't going to work. So maybe we could have a version of multiprocessing that transparently works in a completely different fashion under the hood but it seems like the module should still exist and be usable.

On Wed, Oct 21, 2009 at 3:57 PM, Dino Viehland <dinov@microsoft.com> wrote:
I'm game, I just have reservations about doing this - something like multiprocessing that isn't multiprocessing means certain things/expectations applications might have could break in a dummy context. Since we're derailing, I'm game talking about this privately so we can pass ideas back and forth. jesse

2009/10/21 Dino Viehland <dinov@microsoft.com>
Was it a pain because it was on a builtin or because of the specific functionality? Michael

On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:
+1 to speeding up the gap-closing between 2.x and 3.x maturity and making the fielding of "When shoudl I start using 3.x?" questions easier. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

Nuts, I accidentally sent this just to Guido (again...) Sorry Guido! ------------------------------------- I, for one, am very glad to see this! I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed. I'd like to also point out that the import mechanism (including the concept of the python path, packages, and module initialization) seems to still be messy. For example, getting two copies of the same module when imported with and without a package prefix, and weird import ordering dependencies. I guess these would be covered under the "bugs in the language definition" above. I've wondered too about opening up the whole import process with more hooks to allow other notions of "compiling" and "loading" (for example, being able to import pickles of complex object networks that have been created through some other "compile" process that might still need file modification times checked, but with different file suffixes). This might help to give some degree of extensibility and support for domain specific languages, for example. I agree that Python will gain much more through better implementations than through further additions to the language. (And I don't mean to put down the CPython implementation in any way, it's carried us all a very long way!) Excluding the C implementation from the moratorium makes sense. +1 -Bruce On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:

On Wed, Oct 21, 2009 at 11:14 AM, Bruce Frederiksen <dangyogi@gmail.com> wrote:
I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed.
Depends on your definition of "bug". I would like to see this on a case-by-case basis.
Well, for better or for worse, changing that is *also* going to be messy and a compatibility nightmare. To some extent the details of the import mechanism is up to the implementation anyway, so this may not realistically be affected by the moratorium. If you want to discuss these issues in detail I recommend that you start a new thread and be prepared to hear "but that's just pilot error" about many of the perceived "bugs".
Actually, I think we already have enough import hooks, and this is an area where I would tread very carefully. There is nothing stopping people from using these mechanisms now, but still they are rarely used -- I don't expect that adding new types of hooks will change that.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 1:14 PM, Bruce Frederiksen <dangyogi@gmail.com>wrote:
I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed.
I suggest allowing an exception for changes that make life *easier* for alternative implementations. That would allow for fixing "bugs", making small improvements to new features added in Python 3, etc. As long as it passes the test of making life easier for alternative implementations instead of more difficult. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

On Wed, Oct 21, 2009 at 11:45 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
This is reasonable. We should discuss this at the Language Summit at the next PyCon. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:
I can't disagree with the sentiment, and I wholeheartedly agree with the idea that shifting the focus from language development to library development is a good idea- but I would caution against making the moratorium too hard-and-fast, or too long lasting, assuming that the goal isn't to make it de facto permanent. Towards that end, I'd also like to propose a very public, very accessible 'sandbox' specifically for the development and testing of new language features while the moratorium is in effect. Its goal would be to keep interest in changes to core language design ongoing by keeping the barrier to entry low, while simultaneously separating it from core development. With any luck, it would mean that when the moratorium lifts, Python will be able to take its pick from the best of the language proposals, while still having given other implementations the opportunity to study their behavior "in the wild" for a period of months or years. Geremy Condra

On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <debatem1@gmail.com> wrote:
I can't stop people from forking the language to do experiments, but one of the goals I have for the moratorium is actually to *reduce* the interest in core language changes, and to *raise* the barrier to entry. Most language change proposals are just fluff, and they will be just as unneeded three years from now as they are today. Once the moratorium is lifted, users should be able expect the normal, slow, conservative evolution of the language to continue -- not to see the floodgates lifted for a barrage of new features. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 3:02 PM, Guido van Rossum <guido@python.org> wrote:
Granted that most language change proposals could only be described as "terrible" by a person of unusual charity, but if the goal here isn't to permanently forbid all changes, then it makes sense (to me) to ensure that we're in a better position when we leave the moratorium than when we go into it. Right now, the barrier for proposing a language change is pretty much nonexistent- you dreamed it up in the shower, read about it in a trade magazine, your dog told you it was a good idea, doesn't matter- put it on python-ideas. The problem (as I see it) is that after proposing the idea, wasting a lot of time, and causing a lot of drama, the fact remains that even if the OP finally gets their way, the odds are good that it will take a substantial amount of work from people who have better things to do- the core developers- to make it work. And it only gets worse for the other implementors, who probably didn't have as much input in the process as the CPython devs did. Changing the way that core language changes are proposed and evaluated changes that a lot, though. In the scenario I've proposed, we are in effect saying "write the code and if it gets a lot of support we'll talk about including it in a few years". It shifts the responsibility for development from the core dev team to the one proposing the change. I'm confident that that alone would cut out most of the proposals on python-ideas, while ensuring that whatever was up for consideration at the point where the moratorium lifts was high-quality, well thought out code that had probably been looked at pretty closely by other implementors for several years. Personally, I think that's a much better place to be than either where we are now or where we'll be in a few years without some sort of brainstorm bin. Geremy Condra

On Thu, 22 Oct 2009 06:02:29 am Guido van Rossum wrote:
I was going to make a similar suggestion to Geremy, an official experimental branch in perpetual alpha, specifically to allow people to experiment with language changes. This doesn't mean that when the moratorium is lifted there will be a sudden flood of new features, radically changing the language: features will still need to go through precisely the same procedure to be accepted into the language as they do now. But it will be a place to point people and tell them "don't just tell us how you imagine this feature will work, show us". (For the record, I'm not suggesting that this experimental branch should be open to commits from anyone. You still have to convince those with privileges that your patch is worth looking at.) As far as the moratorium goes, I'm going to be the negative-nellie who says that I don't think this will actually make much practical difference. Python is, and always has been, very conservative about adding new language features. And so far, we've only heard from one developer of another Python implementation, Dino Viehland of IronPython, who said that language features are generally not a problem for him. As far as I can see, the only practical difference it will make is that it will cut short some (but not all) threads on python-ideas and comp.lang.python: anyone who suggests a language change will be told "Moratorium. Come back in 2013." This risks giving newbies the impression that Python is moribund and closed to new ideas -- not just the amateur language designers who have a wild and wacky ideas, but also those with clue who have good, thought-out ideas, as well as the quiet ones who don't have ideas but like those who do. Programming language popularity is not quite a zero-sum game, but languages do live or die by the ability to attract and keep new users. Particularly in Open Source languages, those users tend to be attracted more by "fresh and lively" than "stable and boring". So this is a cost that needs to be considered against the dubious (to me at least) proposition that a feature-freeze in the language will speed up uptake of 3.1. If library authors are going to support 3.x, they need to pick a minimum version and write for that. A new-feature freeze for 3.2 and 3.3 isn't going to make their life easier if they're writing for 3.1, for the obvious reason that they need to use only features available in 3.1. The only language changes that hurt them are non-backward compatible changes like the removal of features, but even there the benefit is minimal because Python already is very cautious about backwards compatibility. Features aren't removed or functionality changed without a long deprecation period, possibly even longer than the proposed moratorium. So I'm not convinced that this moratorium will actually give any advantage. -- Steven D'Aprano

On Thu, Oct 22, 2009 at 1:47 AM, Steven D'Aprano <steve@pearwood.info> wrote:
+1 for the sandbox idea. If crazy suggestions that come to python-ideas are plainly rejected because of the moratorium then I'm -1 on inventing discussion killers. If the moratorium PEP shows how a new language feature is to be introduced in an official sandbox etc, then I'm +1 for the moratorium. --yuv

On Thu, Oct 22, 2009 at 12:26 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
We can call it "the officially sanctioned area for the discussion and development of unsanctioned extensions to Python", then. Or TOSAFTDADOUETP, for short. I kind of like that last one. Geremy Condra

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
Perhaps you're interpreting it as “sandbox of official things”? That would appear to be an oxymoron. My interpretation of it was more like “place with official status as a sandbox”, which isn't an oxymoron IMO. -- \ “I still have my Christmas Tree. I looked at it today. Sure | `\ enough, I couldn't see any forests.” —Steven Wright | _o__) | Ben Finney

On 21 Oct 2009, at 16:47, Steven D'Aprano wrote:
It would be a shame to discourage new ideas just because we are not willing to implement them "now". I hope that any moratorium would not cut discussions of new ideas short, would not change the tone of python-ideas, and would not discourage writing PEP's for new language features (with the understanding that it will be a while before they actually get implemented). Jared

On Thu, Oct 22, 2009 at 5:15 PM, Jared Grubb <jared.grubb@gmail.com> wrote:
Actually one of my goals with the moratorium is to discourage discussion of certain ideas that keep coming up forever and draining the energy of the list. Also, I certainly don't hope that when the moratorium is lifted there are 20 language PEPs waiting for approval. Python's evolution needs to slow down as the user community grows. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, Oct 22, 2009 at 8:31 PM, Guido van Rossum <guido@python.org> wrote:
Personally, I think mandating that you bring working code to the table when proposing a language change would take the number of requests for, say, removing the GIL to pretty much nil.
Again, I doubt that very many of the people proposing some of these changes have either the technical skills to pull them off or the patience to maintain them for a year and a half while waiting for the moratorium to lift. My guess is that you'll have about 300 half-baked or just-started projects and only one or two good ones ready for PEP consideration. Over the period of time you're talking about, that doesn't seem -IMO- to be too much, too fast. Your mileage may certainly vary. Geremy Condra

On Thu, Oct 22, 2009 at 5:57 PM, geremy condra <debatem1@gmail.com> wrote:
Actually removing the GIL is not subject to the moratorium, and it seems that some people *are* working on code.
I hope to discourage those 300 people to the point where there won't be any half-baked or unbaked projects. Let them contribute to Perl 6. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, Oct 22, 2009 at 9:07 PM, Guido van Rossum <guido@python.org> wrote:
Alright then, adding default arguments that evaluate when the function is called.
The trick is figuring out in advance which is the 300 and which is the 1 or 2. My suggestion is that we allow them to effectively self-select; that we allow those who are skilled enough and patient enough- and who happen to have ideas of unusual merit- to prove that to the Python community. If the results are great, great! Two years down the line Python has a great new feature. If not, oh well- it's not like you are under any obligation to merge it. And there's probably merit in keeping the really wretched ones around too, if only to say "no way, tried it, had to kill it with fire". Either way, Python wins. Geremy Condra

On Thu, Oct 22, 2009 at 8:04 PM, geremy condra <debatem1@gmail.com> wrote:
I hope so. But no feature is an island. They must work together. Two or three features that are each individually well thought-out and implemented in separate branches might still be a disaster when combined. Also, ten new features, even if they all fit together, may just be too much new stuff for the user community to digest at once. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, Oct 22, 2009 at 11:38 PM, Guido van Rossum <guido@python.org> wrote:
Exactly- with a sandbox in place, the community could look at real code and evaluate features not just as abstract ideas, but as real working implementations- a first chance to see how well they might work in practice, how much code they break, and how well those changes work together, or, as you point out, don't. Geremy Condra

On Thu, Oct 22, 2009 at 8:45 PM, geremy condra <debatem1@gmail.com> wrote:
You keep stressing the opportunities for new features, but I want to crush that hope -- new features should be rare, and should become rarer as the user community grows. The time to experiment was approximately 10 years ago. Go invent a new language (and hope for it to become popular :-) if you want to experiment. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, Oct 22, 2009 at 11:50 PM, Guido van Rossum <guido@python.org> wrote:
I don't know how many more language changes we'll see in Python- I don't think anybody does- but if the intent is that the moratorium lift at some point, then I would suggest that we should start preparing for that time now. Geremy Condra

On Thu, Oct 22, 2009 at 11:50 PM, Guido van Rossum <guido@python.org> wrote:
Let me add an addendum to my previous comment, because as I reread this it just strikes me as sounding so ominous. Is it really your intent that Python's development slow to the same crawl as Fortran or C? Put another way, is it your intent to eventually raise the moratorium? Geremy Condra

On Fri, Oct 23, 2009 at 5:50 AM, Guido van Rossum <guido@python.org> wrote:
Crushing hope and pointing people to the door is ugly [*]. Why freeze? Instead, define how change occurs and make it as slow as you like. Define the python kilo (1000x) development cycle. For example the "moratorium" could state: --- S&B = syntax and builtins Python only introduces syntax and builtins once every X years[**] and only in major version changes. Between pyNk releases S&B are locked. New S&B can and should be tested on the next major revision's experimental branch(es). New S&B will only be considered for inclusion during the 2 years prior a pyNk major version. If a core language feature is to be accepted it needs: 1. A community tested and reviewed patch 2. A migration strategy (ie 3to4 code). 3. Python-dev acceptance (which can only be applied for during the 2 year S&B period). --- I suggest a new mailing list titled "python-experimental" for discussion and development of experimental branches. Also, commit privileges should be really common and easy to get for this branch of branches. Mercurial could help in implementing this. I realize that anyone can take the python source and do whatever they want on any free source host but having an official lab[***] for this can give another step between code that's in the wild and code that's in an official (non-experimental) branch and thus save core developer's time. --yuv [*] Beautiful is better than ugly. [**] There were about 8 years between python 2 and python 3, extrapolating from the discussion that this was too fast, lets say X=10, sound reasonable? [***] I prefer to call it a "playground" but now that python's all serious business and not a language for fun I don't know how well that would go. ps (short for pike shedding) - the "moratorium" has an evil sound to it. All python needs is a Core-Feature-Development-Cycle-Roadmap or something catchier.

On Fri, Oct 23, 2009 at 3:46 AM, Yuvgoog Greenle <ubershmekel@gmail.com>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. What the moratorium is saying is that the Python language will no longer evolve on the CPython implementation. The moratorium will never be lifted for CPython. When a new implementation comes along, that new implementation will necessitate it's own language changes and have it's own future. The moratorium will be lifted when this new implementation (whatever that ends up being) is chosen. And then the Python language will be riding a new horse, with a new reference implementation. The real questions (if this is even in the right ballpark), are along the lines of: 1. How will this new implementation be chosen? What qualities are we looking for? Are we opening up a contest? Are there deadlines? 2. Will there only be one winner, or might there be multiple winners (perhaps one for each platform)? 3. How will the group of developers now working on CPython transition to this new implementation? This is especially ticklish when we realize that it will be some other group that initially develops the new implementation to the point of being accepted. Does the current CPython group simply ride off into the sunset at that point? Is Guido really the BDFL (Benevolent Dictator For the Language), or only the BDFC (Benevolent Dictator For CPython)? (I, for one, would very much like to see the current group continue to hold the reins on the language. They have an outstanding track record in language design!) 4. What are the legal issues? Are there restrictions on which license the new implementation can use? How is it adopted by the PSF? What limits does that place on the other group that developed this thing? What do they have to agree to? There, I said it. Lock n Load!

On Fri, Oct 23, 2009 at 10:49:37AM -0400, Bruce Frederiksen wrote:
The moratorium will never be lifted for CPython.
Why do you think so? Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

Let's wait for the PEP before derailing this discussion any more. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Bruce Frederiksen wrote:
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 ---------------------------------------------------------------

On Fri, Oct 23, 2009 at 11:45 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Agreed.
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.
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.
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.
Agreed.
Agreed.
Actually, that's almost exactly the opposite of what Guido said- that there will be no one-change exceptions.
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

On Fri, Oct 23, 2009 at 9:18 AM, geremy condra <debatem1@gmail.com> wrote:
I need to give my elbow more rest for a couple weeks, so I'm limiting myself to ultra-short emails. I take exception to "popularly supported" above. Python is still not a democracy. You can fill in the rest. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

2009/10/23 Guido van Rossum <guido@python.org>
Despite the title this was never really a 'proposal' was it. ;-) All the best, Michael

geremy condra writes:
Didn't say it was a democracy. Assumed that it would still involve some input from its user base. Is that wrong?
Your phrase "popularly supported" is ambiguous. If you mean "attracts widespread support in the form of description of varied and plausible use cases" for new syntax and built-ins, or something like that, I'm sure the answer is "yes". The question posed by the moratorium proposal is, "When?" It seems to me that what Guido is heading for here is very similar to the "punctuated equilibrium" concept (associated with the evolutionary biologist Stephen Jay Gould, the wikipedia article is pretty good, and fairly short). The basic idea is that long periods of relative stability are "punctuated" by periods of rapid evolution. In biology, the "bleeding edge" involves literal deaths, and Nature doesn't hesitate to waste large percentages of a population over the "stable" period as well as decimating it during the rapid evolution phases. In software, it may make sense to have the stable periods be *much* more stable, since artificial systems are more fragile than natural ones. C, because it occupies an "ecological niche" as a high-level assembly language, has been quite static since its original definition, even when it evolves. Python need not be, since its niche is very different. But it makes sense to propose to compress the evolution into short periods with many changes, and have very stable periods of "moratorium" between. Whether it will work well or not, we'll have to try it to see. But it's not just Guido's intuition that says it will work to the advantage of Python.

Stephen J. Turnbull wrote:
I was going to stay out of this discussion, but I find it highly annoying to see all these references to C being "static". One need only glance at the length of GCC's changes for the major version numbers to see that it is not static by any stretch of the imagination. Furthermore, the abundance of code revision (even in Python itself!) to compile without warning or error in various version of C compilers over the years makes the label "quite static" as laughable. I believe what you really mean, and what everyone really means, is that there is a core language that is unchanged over long periods of time. Changes that caused previously compiling C programs to no longer compile correctly would be considered a blatant failure of the compiler. That is not to say there are "no new features," rather only features that are backwards compatible. As is repeatedly pointed out, people who really do high-quality, professional development for Python do not develop for the latest release of Python, they standardize on a minimum version number and use only the features in that language; this is no different than writing ISO C90 code rather than ISO C99. I fail to see how this is not *already* the model that Python and Python developers are already using. At it's heart, I think the point of what Guido proposed is for everyone to stop fscking with the language and just start using it (specifically the 3.x version of it). But, I think Guido's frustration with the lack of traction of 3.x is misplaced; it's less than a year ago that it was released, and many ignored 3.0 due to the io module. Nevertheless, it is Guido's language and he can do whatever he wants. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

Scott Dial writes:
What does the ChangeLog for an implementation have to do with the stability of the language definition? Guido's moratorium does not attempt to regulate adaptation to new platforms, optimizations, or changes to improve conformance to the language reference, and (AIUI) not even changes to improve conformance of the implementation to programmer expectation where the language reference was ambiguous. Surely the vast majority of GCC changes fit one of those categories. Seems to me you have made a very powerful argument-by-analogy that Guido's moratorium provides plenty of room for hyperactive core development.

On Sat, Oct 24, 2009 at 1:30 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Let's just clear up a misconception: I am *for a moratorium*. As in, +1 from me. Having said that, I do not agree that development on changes to the language should stop, just that it should stop being integrated until we've had a long breather, allowed the other implementations to catch up to some degree, and given ourselves time to assess what the actual state of the language is post-2.x. The problem is that once we're out of the moratorium we'll be back in the same situation: every change will put the other implementors behind the one with the most man-hours to devote to it, we still won't know how any two changes to the language will interact, and we still won't be able to reasonably and empirically evaluate the worth of any particular proposed feature. We'd need another moratorium straight off. My solution to this problem is a simple one: create a sandbox where we can leverage Mercurial's ability to create cheap and easy branches to get a glimpse of possible future Pythons. We allow people to keep coming up with ideas and keep developing ideas on the off chance that one of them works so well that we want to integrate it after the moratorium lifts. There is no obligation here, no demands made on anyone's time who does not care to take a look at whats happening in the sandbox. In a few words, there is no cost. If done properly this will give both the CPython user base and the other implementors a period of not weeks but months or years to evaluate a proposed change to the language; it will force those proposing such changes to actually come up with code to match them, sparing the core devs time that could be better spent on the libraries or on improving Python 3 support in the community; it might even help thin out the requests for those features that are likely to be rejected, since seeing that an implementation has been rejected is frequently more compelling than hearing that a similar proposal has been dismissed in the past. As I say, it seems like a good idea to me, and if it turns out later not to have been it has virtually no consequences. Others will doubtless have different opinions. Geremy Condra

geremy condra wrote:
Note that one of the major reasons behind moving to a DVCS at all it precisely to make it easier for people to collaborate on such experiments without having to involve python-dev. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Sun, Oct 25, 2009 at 1:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I'm a little unclear on what you're driving at here- my goal is to keep these projects off the minds of the core devs until they're about ready to go, to make it easy for all the implementors to carefully assess both the features themselves and the code used to implement them as they near that point, and to make certain that there is a common point of reference for the debate over inclusion afterwards. In other words, not specifically to remove python-dev from the process, but rather to allow it to spend its time more productively elsewhere until it can be usefully spent there. Geremy Condra

geremy condra wrote:
Having an "official sandbox" is completely irrelevant (and probably counterproductive) if core development is happening in a DVCS. If people want to experiment, they will be able to experiment by branching into their own repository. Trying to create an "official sandbox" (or, more likely, use the existing sandbox) defeats the whole point of the exercise, since it just brings the CPython admins back into the loop and will generate a pile of irrelevant traffic on python-checkins. In short, a moratorium that said "we won't accept things into trunk, but you can still pester us to add things to our official sandbox" would be a pointless exercise. Moving to a DVCS, putting a core language change moratorium in place for a few years, then looking to see what improvements have been developed outside the core tree as the moratorium is running down (and what feedback has been received over that time) would be far more sensible. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Sun, Oct 25, 2009 at 12:01 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
But the merges into the core will be tough. Imagine submitting a 5000-line patch and saying "I've worked on this for a year, please adopt it." Will we do enough code review to assert the code quality? -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.

Guido van Rossum schrieb:
I can see two remedies: * The branch changes are structured in relatively short, well-reviewable commits. Less likely for a branch worked on for a year though. * A core developer is involved from the start and acts as a just-in-time reviewer. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Guido van Rossum <guido@...> writes:
Pardon for hijacking the moratorium discussion, but this is the kind of problem we already have with externally-maintained modules (such as json). The way they are updated is that once in a while (once a year perhaps), their author comes with a huge patch that we should ideally review, except that it's very difficult to do so -- especially given that it's about a piece of code that we don't know well in the first place.
PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
I hope you'll get better soon! Regards Antoine.

Antoine Pitrou schrieb:
But we haven't really put a review policy into place for core commits, and since the authors of those packages all (?) are core devs, we trust them enough to commit to the core. It's different with DVCS branches created by "only" community members.
+1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Sun, Oct 25, 2009 at 2:18 PM, Georg Brandl <g.brandl@gmx.net> wrote:
<snip> My suggestion then would be to review them. There's a couple of years lead time before that needs to be done, and there will probably only be a very small number of these projects that ever bear any fruit. As I said in another thread, if thats not enough time to attract some developer's interest, then the feature probably wasn't good enough to land anyway. Geremy Condra

On Sun, Oct 25, 2009 at 12:29 PM, Guido van Rossum <guido@python.org> wrote:
Frankly, if a feature isn't interesting enough to convince a core dev to take a few good hard looks at the code over the length of time you've proposed for the moratorium, it probably doesn't deserve to be in the language anyway. At least, that's my view. Geremy Condra

On Sun, Oct 25, 2009 at 3:01 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I don't see any evidence for either of these claims, and IMO the argument that somehow allowing people to "go play over there" until they've got something that could seriously be considered for merging is going to slow down core development is a little silly.
I don't see the sandbox working this way. I see it being somewhat more separated from the official core, probably to the point where it wouldn't generate checkin messages and hopefully to the point where it wouldn't require a dev to start a publicly viewable branch. This also avoids the problem of having to go through a kajillion different places to see what kinds of proposals have active support or are close to completion and which aren't, which should help to discourage people from duplicating effort, as well as giving the various implementors more advance warning on what might be coming down the pipe.
You see the difficulty of occasionally reviewing a substantive, testable proposal for a language change as being enough to outweigh the advantages Guido has attributed to the moratorium? And here I was thinking that adopting a code-first-jaw-later approach would save the devs time.
That's the goal, I'd just also like to have all those improvements centralized for easy review and comparison. Geremy Condra

geremy condra writes:
Given the degree of decoupling you describe, there's no need for Python to host anything more than a simple CGI for registering remote branches. Probably for the purpose we have in mind the CGI should check that it actually *is* a branch of an official Python branch.
It's a waste of their effort to "play over there" in hopes that their feature will ever be considered. If it's small enough to be considered and approved without a major use case, it probably can be maintained as a patch on the tracker indefinitely.
This is a chunk of management effort to do properly. Take a look at git.kernel.org and tell me which of those branches matter, and to whom. Unless you're a kernel activist, I bet you cannot.
It would. But consider the PEP for ipaddr. That discussion was a total waste of everybody's time because the proponent never put forward a use case in working code for the most controversial feature, making it impossible for anyone to figure out WTF he was thinking. It turns out he wasn't thinking about anything at all, the "feature" was merely an artifact of his implementation, and he didn't understand what others were talking about. When he finally did get around to thinking about what they were talking about, he immediately accepted a sensible proposal, the compromise was accepted with some grumbling, and work can proceed. I forsee lots and lots of those if the only code to review is the implementation of the feature in the officious sandbox. Much better if we can look at the big picture in the context of a real app developed wa-a-ay over there, and a sub-repo containing the relevant branch of Python core. Since it *is* a branch of Python core, you just clone the core, and do "hg merge" and you've got a reviewable implementation.
That's the goal, I'd just also like to have all those improvements centralized for easy review and comparison.
There will be way too many of them to be reviewed at all, let alone easily, if all people have to do is post a branch to an official sandbox.

On Sun, Oct 25, 2009 at 11:28 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Hadn't thought of that. I'd prefer that there be a hosting facility involved, but it's a long way from being critical- assuming the other objections to the sandbox could be settled, this would get a +1 from me.
There is an enormous risk that they are wasting their time. The goal is to save the core devs' time, not those proposing features.
I don't envision this ever reaching the scale of the kernel, and if you feel there is any risk of it doing so then I suggest we implement it ASAP, since there are evidently thousands of heretofore unseen core developers with a curious aversion to centralized version control systems.
I honestly don't see what this has to do with this proposal. 1) ipaddr made no effort to change the language itself, and would in any event be eligible for consideration under the normal rules during the course of the moratorium. 2) the situation was complicated by recriminations about the openness of python, the role of the mailinglists vs the bugtracker, and numerous other issues that we don't need to go into here. That such a wide-ranging discussion would cause consternation should surprise no one. 3) According to people who know a great deal more about netmasks than I ever will, the things the author was unaware of would fill several large books, and even Guido repeatedly emphasized his lack of knowledge on the subject. By contrast, the group of core Python developers is uniquely qualified to talk about changes to the language's syntax and behavior.
We're talking about changes to the core language. I would suggest that the only "apps" possible under those conditions would be extensive test suites and real-life use. Realistically, we can only have the former without large-scale acceptance of a program similar to, but larger in scope than, the one I am proposing.
I doubt this. Experience suggests that the number of individuals proposing changes with the technical chops to pull them off is relatively small, and my own admittedly limited familiarity with human nature leads me to conclude that the formidable obstacles piled along the road to acceptance will discourage all but the most determined proposals. Geremy Condra

geremy condra writes:
The core devs' time will be saved by ignoring the sandbox (other than their own features), and if it intrudes on them (eg, in the commit notices), they will request that it forcibly be shut up. Cf. the short exchange you had with Nick on the subject of commit notices. ISTM that rather the goal is to ensure that features that would otherwise be overlooked or be blocked because the proponent is unwilling to follow through to the extent required (ie, by a new proposal at the time of ending the moratorium) be given more consideration. I don't think a sandbox will help with that, unless it is designed to give incentives and help in producing *better* proposals. Just collecting them in one place is not going to help.
It would. But consider the PEP for ipaddr.
I honestly don't see what this has to do with this proposal.
It's a common pattern of discussion, for both stdlib and core syntax/builtins, and I chose it because it was close to the boundary of approval. I didn't want to choose nonstarters like multiline blocks or trivial suggestions like a warning for "breakless for-else".
Are you sure you're not confusing it with the distutils thread(s)?
But those are precisely the people whose time you plan to save. The only way to save their time is to do less reviewing. Having an official sandbox might do that by giving the dross a place to collect, so the core devs *never* look at it.<wink>
Yup. Precisely the kind of stuff that happens in real projects, not in sandboxes.
Sure, but they generally also are core developers. I don't see why an "official sandbox" will be of use to them.

On Mon, Oct 26, 2009 at 2:12 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Until a feature because quite mature, yes- afterwards, no. That's the point of keeping it separate.
I've already addressed that, see the messages you reference.
Nope, not the goal.
No, it wouldn't. Because that's not the point.
Pretty sure.
Yes it is.
The only way to save their time is to do less reviewing.
Nope, pretty sure that coming in to do a code review at the end is less time consuming than being involved with a feature from the beginning.
Having an official sandbox might do that by giving the dross a place to collect, so the core devs *never* look at it.<wink>
I like to think that the fact that a patch comes from outside of core will not impact its consideration by that group.
True, and irrelevant. The sandbox I propose is not the existing python sandbox. Choose a different term for it if you want, but anything in it that wants acceptance had better be damned good, and that, in my mind, includes thorough testing.
Some core devs may decide to use it to produce features that aren't going to come in under the moratorium, but people outside the core dev group can also use it. Don't assume that the only people with the experience and knowledge to implement such a change are part of the core dev group- especially a couple of years from now. Geremy Condra

geremy condra writes:
On Mon, Oct 26, 2009 at 2:12 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
The core devs' time will be saved by ignoring the sandbox (other than their own features),
Until a feature because quite mature, yes- afterwards, no. That's the point of keeping it separate.
I see what you're saying, my assessment is that it will not be as effective as you think. Your assessment is different. Only way to prove it one way or the other is to try it.
I don't make that assumption, it's an empirical observation of current conditions, backed up by the observation that new people have been gaining committer status regularly over the time I've watched Python-Dev -- if you've got the Right Stuff, there are few barriers to joining the core. I agree with you that they won't be the *same* people that are around today, but they will most likely be in the core.

On Tue, Oct 27, 2009 at 8:49 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I suggest we do that then. I'd appreciate input on how to structure it- the CGI idea (I believe it was yours?) seems to me to be the best on the table right now, but I'd like to hear contrary points of view.
If they're in core, so be it- I'm fine with that. But especially as the language's user base gets larger I suspect we're likely to see proposals that reflect a pretty diverse range of views on what Python should look like. Python-dev isn't the right place for a lot of those, especially while under the moratorium, but we still ignore them at our peril. The sandbox gives people a place to experiment with possible future Pythons in a way thats low-impact on the parts of the community that aren't interested in it. We disagree on how big the interested group is and who it contains, but my vote (for whatever its worth) is that we should find out. Geremy Condra

geremy condra writes:
Let's just clear up a misconception: I am *for a moratorium*.
I don't think anybody said otherwise. So, in the meantime, you propose a "sandbox":
... it will be work for somebody.<wink> Doing things properly always is. As Nick points out, Mercurial already allows that personal sandboxes, quite cheaply. Why should python.org and/or the PSF provide such a sandbox? I can think of one reason: providing a place to showcase new features in variants of the major implementations that are in actual use in other projects, and to collect common code of the various implementations so it can be shared. Maybe there's room for some speculative features, but I don't yet see that as a primary purpose here.
As I say, it seems like a good idea to me, and if it turns out later not to have been it has virtually no consequences.
That would be a shame if it works out poorly partly because it's been sold as cheap and risk-free, and as a consequence nobody puts in the resources needed to "do it properly".

On Sun, Oct 25, 2009 at 4:34 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I wouldn't be advocating it if I weren't willing to put in the resources- but it won't actually work unless it has support from both the python-dev and python-ideas communities. Having said that, I do see it as being cheap and risk free because if it never sees wide use then it will simply fade into the night, another one in the thousands of places that people can publish a repository, which is, as Nick and others have pointed out, the status quo for the duration of the moratorium. Geremy Condra

On Sat, 24 Oct 2009 04:30:36 pm Stephen J. Turnbull wrote:
I argue that you've got it backwards. Python has been relatively stable in the ways that matter for almost all of it's history. Nearly all the changes to the language in 1.x and 2.x have either been backwards-compatible, or managed carefully with a deprecation schedule or __future__. The result of this is that code written for Python 1.5, and possibly older, will still work in Python 2.6. It's easy enough to ignore new features if you need to support an older version. This does not apply to 3.x. If you want to see punctuated equilibrium in software development, the change from 2.x to 3.x is an good example: a relatively large change in a non-backwards compatible way, with no gentle migration path. Supporting 3.x is all-or-nothing: you can't support 3.1 and 2.6 with the same code base, except possibly for the most trivial code. I suggest that the causes of the slow uptake of 3.x isn't too many changes to the core, but three factors: (1) There's no gentle migration path from 2.x to 3.x in the same way that there have been gentle migration paths from every version to the next version in 1.x and 2.x. Instead you've got a discontinuous change. Library maintainers have to choose between: - support 2.x only - support 3.x only - maintain two incompatible code bases. The path of least effort is to support 2.x only, because they're already doing that. (2) For many people, 3.x doesn't offer any obvious compelling advantages over 2.x. (Of course, your mileage may vary.) Reading the What's New for 3.0, I see *many* nice features and cleanups, many Nice To Have new features, but no obvious Must Have to encourage me to migrate. http://docs.python.org/dev/3.0/whatsnew/3.0.html (3) It's the bootstrap problem: most systems that ship with CPython still ship with 2.x, and will continue to do so until people are regularly using 3.x, but people generally use whatever their system ships with. I don't see that a moratorium on new features will help with any of these issues.
In software, it may make sense to have the stable periods be *much* more stable,
The principle of "release early, release often" argues against that claim. The 2.x series has been very successful. Why change a successful procedure for one which is, at best, unproven, and at worst, condemns the language to the (unfair) label "moribund"? I don't believe that the experience of the C language is relevant. The C *standard* was stable, but actual C compilers evolved like mad, providing non-standard features. Because C is so low-level, the difference between a built-in and a library is very slight.
But it makes sense to propose to compress the evolution into short periods with many changes,
As has happened in the change to Python 3.x.
and have very stable periods of "moratorium" between.
We keep coming back to this idea that the volume of change in a language is, in and of itself, harmful. I dispute that. It is *incompatible* change that is harmful. Developers have been slow to move to 3.x not because it's different from 2.x, but because it is different in inconveniently incompatible ways. There have been some major new features in the 2.x series, e.g. new-style classes, generators and decorators. As far as I can tell, those versions didn't suffer from lack of uptake as 3.x has suffered. It's not new features that frightens developers off, but incompatible change. -- Steven D'Aprano

On Sun, Oct 25, 2009 at 4:22 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Much though I like the writing of Gould and others, and much though we talk about Python "evolving", I don't think that punctuated equilibrium makes sense as an analogy, no matter which way to turn it. The proposed moratorium is a *conscious decision*, an intentional policy meant to have a certain effect. This is just the opposite of evolution in nature (unless you believe in "intelligent design" :-). [...]
I suggest that the causes of the slow uptake of 3.x isn't too many changes to the core, but three factors:
While I mentioned 3.x in my original message about the moratorium, I didn't mean to imply that the moratorium would solve the slow uptake directly. The intent was to give people who would otherwise work on language change proposals more time and motivation to work on porting 3rd party packages to Py3k. Also to give other implementations (in particular PyPy, IronPython, Jython) more breathing room to catch up. Also to stop the pointless discussions about anonymous blocks (though that may have been naive :-). -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.

On Sun, Oct 25, 2009 at 8:51 PM, Guido van Rossum <guido@python.org> wrote: <snip>
Tell everybody that proposes it to show you the code. 99% of them will STFU, and it's probably worth a little bit of time to see what the other 1% come up with, even if its never going to get in. Worst case scenario, you've spared yourself the headache of dealing with people who can't (or won't) help you implement what they so urgently desire. Best case scenario, maybe you even get a great feature out of it. Geremy Condra

geremy condra wrote:
There's no point telling people to produce code for a design that isn't acceptable in the first place. No anonymous block proposal has ever even made it past the first hurdle of being better in concept than a named function (which do have their downsides, but those have always been looked minor when compared to the downsides of the proposed additions). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Mon, Oct 26, 2009 at 6:05 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
The point is that almost none of them will do it, and if somebody is so determined that they'll actually jump through all these hoops to get the feature, maybe it really *is* needed for something they're doing. In any event, by the time they've done that they deserve to be taken more seriously than the person just randomly jawing off. Plus, not all features are as pointless as multiline lambda, but almost all proposals for language change are being sidelined by the moratorium. We should provide a facility for those ideas to be identified and developed (by third parties) during the moratorium so that we have time for a careful and thorough review- in effect giving ourselves a solid one to two year head start on any future language changes. I might even go so far as to say that under this model a kind of rolling moratorium might be a good idea- a mandatory period of substantial length during which a change to the core language has to be reviewed by the devs, the community, and the other implementors for its viability and usefulness. But that's probably something to be decided by higher-ups later on. Geremy Condra

Guido van Rossum writes:
By Clarke's Law, I see no way to distinguish between the presence and the absence of intelligent design in nature.
Time, yes, but I'm not sure I see where the motivation comes from. Do you mean something like: remove all hope from "design + maybe implementation" proposals, with the intent of encouraging "design + implementation + clear application to use case" proposals. where porting to Py3k should be a prolific source of use cases? ISTM that has been the desired historical criterion for inclusion in Python anyway. So a moratorium might reduce the number of "frivolous" proposals, but is it really going to encourage work on porting? (Those are all really yes/no questions from my standpoint.) If not, Steven d'Aprano's line that Python has been quite stable anyway, up to Python 3, and so (IIU him C) there's really no need for a formal moratorium, becomes very plausible. That is, since there doesn't seem to be a strong call for a moratorium from the Jython / Cython / IronPython / PyPy end. (So far, that it. I don't suppose the final word has been spoken by those developers, yet.)
PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.
May the Intelligent Designer have mercy on your elbow!<wink>

On Sun, Oct 25, 2009 at 9:07 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
So using Occam's razor we might as well assume there is none.
But hard to answer. Have faith. :-)
We're seeing an influx of new developers. They don't all remember or understand why we had to limit releases to once per 18+ months. The moratorium reminds them and their fans of the importance of *not* adding new features.
I trust my doctor a little more. -- --Guido van Rossum PS. My elbow needs a couple more weeks of rest. Limiting myself to ultra-short emails.

On Sat, 24 Oct 2009 02:45:18 am Nick Coghlan wrote:
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.
"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. [...]
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.
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

Guido van Rossum wrote:
Here's a thought: How about directing the developement effort in a predictable pattern. An example of this might be... 3.2 - library development, and bugs 3.3 - bug fix's only, (long term stable release) 3.4 - core development, bugs 3.5 - library, bugs 3.6 - bugs only, (long term stable release) 3.7 - core, bugs 3.8 - library, bugs 3.9 - bugs only, (long term stable release) Also one of the things I like about Ubuntu's development, is the pre announcement of what areas of Ubuntu will be worked on. I think that has a really good effect on how well development efforts are focused. Cheers, Ron Adam

On Tue, Oct 27, 2009 at 7:02 PM, Ron Adam <rrr@ronadam.com> wrote:
I like this approach to the moratorium because roadmaps are better than roadblocks IMO. I touched it up a bit: 3.0 - New language features 3.1 - Ironing out language features (moratorium starts) 3.2 - library development 3.3 - library development 3.4 - library development 3.5 - library development 3.6 - Implementing features for easing transition to 4.0 3.7 - End of road for 3.x 4.0 - New language features .... etc etc --yuv

On Wed, Oct 21, 2009 at 1:52 PM, geremy condra <debatem1@gmail.com> wrote:
Once the transition to Mercurial is complete, making experimental forks of CPython to play with new language features will be a breeze. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

Daniel Stutzbach <daniel@...> writes:
Once the transition to Mercurial is complete, making experimental forks of CPython to play with new language features will be a breeze.
There are already Mercurial branches, they are read-only but it's sufficient if you want to clone them and create your own branches while still tracking upstream changes. Regards Antoine.

On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:
+1 While there are changes that I'd like to see, a moratorium for a few years would benefit all of us in the long run: - It's easier for companies to justify training. - It's easier to gain adoption for long-term projects. - It's easier to hold the attention of potential contributors for bug fixes. (And for many other reasons, but those are big ones in my book these days.) -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

I think if such a moratorium is instated it should be announced way before the feature freeze of the version that will represent the feature set of the moratorium. So this should have been announced before 3.1 was released. -panzi

On Wed, Oct 21, 2009 at 13:20, Mathias Panzenböck < grosser.meister.morti@gmx.net> wrote:
That's not necessary. If you look at the PEPs that are even remotely going to fall under this moratorium are PEPs 3142, 382, 380, 369, 335, and 286. The newest one, PEP 382, was checked in back in April which is five months ago. This is not about to cut someone off from getting their suggestion into Python that was on the verge of acceptance. If anything this is a good time to do this as the hazy "does this go into 2.7 or not" question has held back new additions to the language. -Brett

On Wed, Oct 21, 2009 at 09:42, Guido van Rossum <guido@python.org> wrote:
+1 from me. In this rather long thread someone proposed allowing changes that make implementation of the language easier, which I am also fine with, but that could almost be classified a bug fix and taken on a case-by-case basis. But completely new exposed syntax or semantics for the language and built-ins should be off limits. And for the "several years", I say make through 3.4, letting in new features for Python 3.5 which should be open for development in mid 2013.
The moratorium should also give us time and space to focus on bug fixes for the language which is good.
Sounds reasonable to me.
Sounds good to me. While I heard some people on Twitter want PEP 380, if we are going to freeze it should be across the board. I can see someone arguing that at least PEP 380 is in a PEP format, but even then that doesn't mean its fully thought out (and I am not explicitly talking about PEP 380 as I have not read it in ages). A side benefit to this is it will give us time to come up with a PEP that clearly defines exactly what is required to propose and get accepted changes to the language (I also want to do this for the standard library, but I view that as a different PEP). Hopefully that will cut down on the wild proposal on python-ideas and give people a much clearer idea of what is required of them. As I view this as a developer doc thing I am willing to write these PEPs (eventually =). One thing I would like to see happen for this moratorium is us following a more rigid release schedule in terms of feature freeze. So I would propose that starting with 3.2 we feature freeze 18 months after 3.2's feature freeze. Now I am not suggesting we lock down the final release date to 18 months as who knows how long it would take to shake out the bugs, but we can easily say that every 18 months we feature freeze for the next minor release (major releases don't apply to this schedule and I am not worrying about micro releases as that is not under discussion here). This would give us and the community a much clearer indication of when the moratorium will be lifted. So we could say that 3.2 is feature frozen on June 15, 2010, Python 3.3 on January 15, 2012, and Python 3.4 on June 15, 2013. We can obviously choose some other set of dates (went with this to avoid releasing on New Years, although it might be fun to shift to Oct 5 as that's the date Flying Circus was first broadcast), but it would be nice to be able to say that "after Python 3.4, which is feature frozen on XXX, we will start looking at new features again for Python 3.5". -Brett

Brett Cannon schrieb:
That's a looong time (for me at least), but still an acceptable timeframe.
Do you really think so, or do you say it because you wish it was true? The occasional syntax change doesn't block many developer resources. IMO it's the tedious interminable discussions on library and infrastructure issues, e.g. distribution/packaging or the future of WSGI, and none of these is going to be cut off or settled.
+1 for predictable release schedules. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Thu, Oct 22, 2009 at 9:18 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Agreed. We'll need to first list out the goals of what we can accomplish within the frozen syntax timeframe, and then look at how long it will take to reach those goals. Only then can we decide how long it would be ideal. Also, even if when this is in effect (+1 fro me by the way), we also need to agree on some kind of exceptions so we're not shooting down at our own feet.

Guido van Rossum <guido@...> writes:
Note, the moratorium would only cover the language itself plus built-in functions, not the standard library.
Out of curiousity, would it preclude adding e.g. a method to a built-in type? (I'm not saying this with anything specific in mind) Regards Antoine.

On Wed, Oct 21, 2009 at 1:28 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
And I can't answer without anything specific in front of me. I think it's time for someone to draft a PEP for me summarizing some of the points of this discussion. Some specific quick responses before I run off to do real work: - no, I don't think it should have been announced before 3.1 was frozen - no, I don't think we need an ISO standard - no, it's not decided yet - no, it's not an absolute law (actually typical laws have lots of gray areas too) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum skrev: problem is not "language changes", but one implementation (CPython) being the "de facto" Python language standard. Maybe there should be a real Python standard? A syntax change in CPython would be a CPython specific language extension (like GNU extensions to C), not a language change. Today, a syntax change in CPython is a redefinition of the Python language. That will be avoided with a standard. Cython (and Pyrex before) adds many extensions to the Python language, while aiming at being compliant with "pure Python". But what is "pure Python" anyway? It would be much easier for everyone if there was a piece of paper defining the Python language -- and possibly certain critical parts of the standard library. Also, an industry standard for the Python language would help adoption of Python in many organizations. Except for Java, only standardized languages tend to be considered for large projects. Many has strict policies of only using standardized languages to ensure availability of compilers/interpreters in the future. Personally I think Python 3000 is mature enough for a standard. Sturla Molden

Sturla Molden <sturla@...> writes:
Isn't this the same as saying it is time to produce an industry standard (as in ISO, ECMA, ANSI, IEEE) for the Python language?
If we had plenty of workforce available it might be an idea. But we have not, and fixing bugs and making improvements is a much better use of volunteer time than language lawyering, IMO.
Except for Java, only standardized languages tend to be considered for large projects.
The "except for Java" statement makes me think that standardization isn't a real criterion here. Stability may be, however. Antoine.

Antoine Pitrou wrote:
I know of a number of large projects that are quite happy to make extensive use of Python. They tend to standardise on older versions (more precisely, versions that were current when the project started), but they use it. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Sturla Molden writes:
Guido van Rossum skrev:
I propose a moratorium on language changes.
Isn't this the same as saying it is time to produce an industry standard (as in ISO, ECMA, ANSI, IEEE) for the Python language?
No. The language reference is quite precise and accurate AFAICS. There may be an argument for an industry standard, but this isn't it.
Would it make a difference? Surely the CPython implementation would still be the de facto "reference interpretation" for resolving ambiguities. Note that many argue that the success of the Internet is due to deliberate adherence to a PEP-like process that involves actually implementing and demonstrating usefulness of new features. OTOH, the ISO and other standards bodies are famous for standards produced by language lawyers. These standards are sometimes unusable, and too often ignored in favor of well-known best practices. In the end, I think it would be hard to convince the developer community to abandon the PEP process. So any ISO effort would be layered on top of it, and CPython would still have distinguished status.

Guido van Rossum wrote:
++1 Yay! I really like the idea of keeping the core small, simple, and efficient, and having most of the real interfacing and data processing *magic* done through libraries. So yes, please refocus development efforts to improving the library. I think if a library could benifit substantually from some core improvement, then that can be discussed at that time. Such improvement to the core will be for a real concrete need to enable functionality in an extension or library, rather than improving the core with expectations of having some unknown abstract or perceived benefit later. Ron Adam

+1 I only wish that the leads of many other software projects I use would be equally wise to declare a moratorium once in a while. It's a sign of maturity and sadly many developers don't realize this and keep adding features all the time for the sake of adding features. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown

On Wed, Oct 21, 2009 at 09:42:01AM -0700, Guido van Rossum wrote:
+1 for the moratorium during the life of 3.2. +0.5 for 3.3. -1 for the reason. In my no so humble opinion the moratorium is a benefit for the language, the implementation (CPython), the developers and the users (software developers that use CPython). If alternative implementations see their benefits - well, good for them. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

[Guido]
Eh. I'll be a solid +1 on this /if/ you use your time machine to begin the moratorium right after the "with" statement was introduced. The rationale you gave applied as much then as it does now -- and if you do this, then we won't need to discuss it now, since it will already have been done. If you won't use your time machine, fine, +0.9. I'm taking off a tenth so you realize there's a steep cost for refusing it interfere with history.

On Thu, Oct 22, 2009 at 11:40 AM, Tim Peters <tim.peters@gmail.com> wrote:
Well, my intention is for it to begin right after 3.1 was released. While the time machine can do stuff with SVN or Hg branches, it's not powerful enough to mess with code already released. Though honestly I don't recall exactly what was added between the with statement and the 3.1 release apart from 'nonlocal'.
Ah, you've moved from fractional winks to fractional votes. A nice upgrade. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 2009-10-22 14:10 PM, Guido van Rossum wrote:
Can you recall, off the top of your head, what language changes would need to be rolled back between the trunk and 3.1? I'm basically +1 from the peanut gallery, but I'm not really sure what changes have already been committed to the trunk.
It's one of the things I miss about the good old days of c.l.py, actually. :-( -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

On Thu, Oct 22, 2009 at 12:48 PM, Robert Kern <robert.kern@gmail.com> wrote:
Not off the top of my head, but a diff between the Grammar file tagged with r31 and the py3k branch's head suggests that the only grammatical change was a refactoring of star-expressions which just fixed an ambiguity. The change of the 'with' statement to allow multiple handlers made it into 3.1 so it's safe. I haven't researched recent changes to the builtins, but svn.python.org is your friend. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

[Guido]
[Tim]
[Guido]
Well, my intention is for it to begin right after 3.1 was released.
Well, I believe that /was/ your intention.
While the time machine can do stuff with SVN or Hg branches, it's not powerful enough to mess with code already released.
LOL -- say that often enough, and the newbies might even believe it <0.6 wink>.
Though honestly I don't recall exactly what was added between the with statement and the 3.1 release apart from 'nonlocal'.
Excellent! My plan worked, then. I looked, and, e.g., both the switch statement and anonymous inline meta-decorators no longer exist in current Pythons. I can live with nonlocal -- its continued existence was probably just due to a local leak in the time machine's rear Tesla coils. They've always been a bit flaky.
If you won't use your time machine, fine, +0.
Ah, you've moved from fractional winks to fractional votes. A nice upgrade. :-)
I have no idea what you're talking about. the-more-things-change-the-more-i-don't-ly y'rs - tim

Guido van Rossum wrote:
As one of the lead developers of the Cython project, which is following CPython at some distance but at fast pace (and high speed ;), I honestly wouldn't mind such a moratorium. As a Python language user, I must say that I cannot remember any recent(?) language syntax proposal on python-ideas that would have made the language substantially better. Plus, a lot of the code that gets written even today is still required to stay Py2.x compatible, sometimes as old as 2.3. Especially library or tooling code will often not even use Python 2.6 features for a while, let alone Python 3.x features. That doesn't mean you can't 2to3 it, it just means that it won't use the new syntax features. I guess that makes a +1 from my side. Stefan

Stefan Behnel wrote:
Dito! The last useful (and today widely used) syntax change in the 2.x series was the 'with' statement. I don't see urgent need for any syntax or language chances in the next couple of year. The only new feature I can think of, that might require new syntax, is parallel processing and executing multithreaded, GIL-less code. Such a feature is going to take a long time before it's implemented. I'm +1 on your proposal, Guido. Do you propose a fixed time span for the moratorium or a status quo? Can we continue changing the language once Jython and IronPython have fully implemented Python 2.7 / 3.2? Christian

On Wed, Oct 21, 2009 at 10:43 AM, Jesse Noller <jnoller@gmail.com> wrote:
+1; modulo getting PEP 380 in before the moratorium ;)
I see the smiley, but just in case you were half serious, I really think we should stick to the policy and not make exceptions for personal pet peeves.
Of course, no moratorium can stop people from *proposing* changes, but it helps core developers and others who "just want to get stuff done" focus if they know we're not changing the language for quite a while. Effectively the moratorium would freeze the language at the 3.1 version at least for 3.2 and possibly for 3.3. Also 2.7 could not add language changes except possibly changes to keep up with 3.1 (but only if *very* strict backwards compatibility with 2.6 is maintained also -- I want the upgrade from 2.6 to 2.7 to be a breeze for everyone). Obviously there are many things we could change in the standard library that would still affect the ability to upgrade easily (see the recent issues with 2.6.3 and 2.6.4), and we should be exercising a lot of restraint in this are as well. But language changes affect other implementations the most (I think). They also coincidentally speak most to the imagination of the young, eager-to-add-their-pet-feature amateur language designer crowd who so often fill python-ideas with heated discussions. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 2:06 PM, Guido van Rossum <guido@python.org> wrote:
The only reason I would argue against that would be for the fact that AFAIK, it's "nearly done and ready" - that being said, that is a specious argument. But I agree - no exceptions makes sense.
Agreed; there's been discussion on disutils-sig and other places (such as the language summit) revolving around a "single, shared" standard library for all of the implementations. So long as the syntax is unchanged, we can upgrade/improve the stdlib over time, and make it used for the various implementations. jesse

Guido van Rossum schrieb:
Well, the moratorium isn't yet in place (which I also gather from you posting that on the ideas list), so would be nothing wrong implementing something before it starts... :) Anyway, I'm not sure how much impact this will have; already there are very few real language changes going on; after 2.6, whose such changes mostly were Python 3 backports. In 2.7, the multi-with syntax is the only real language change so far. (When you say "builtins", do you e.g. include the str.format() mini-language? There has been a lot of work on that lately, to fix ambiguous corner-cases.) I'm not saying it's a bad idea, but while it might stop a few threads on python-dev, it won't change a lot in terms of how core development time is spent. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Wed, Oct 21, 2009 at 11:24 AM, Georg Brandl <g.brandl@gmx.net> wrote:
No, the moratorium would freeze the language at the version implemented in 3.1. If necessary we'd have to roll back core language changes (primarily syntax, or new builtins) made since 3.1 was released.
I think fixing ambiguous corner cases can proceed.
My main goal is to set expectations right -- people who spend effort porting to 3.1 should not be confronted with further effort caused by the upgrade to 3.2. (An alternative would be to postpone the release of 3.2 until the moratorium is over, but this would unnecessarily constrain further development of the library.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido wrote:
This generally sounds nice for us and will make it easier to catch up to 3.x as well as make it easier to continue to flush out other missing built-in modules. But I would actually be really happy with just a partial freeze though - I actually find support for new standard library features is typically the biggest hit for us and that core language features (modulo import related features which are always difficult ) have generally not been an issue. For example consider multiprocessing - which IronPython still doesn't support. That's a much bigger work item than everything that changed related to parsing in 2.6. New built-in functions can also be a huge pain - again compare float.fromhex to everything that happened to the parser in 2.6. I'm pretty sure I spent more time on float.fromhex even w/ the already existing awesome test suite. So I definitely think not adding significant new functionality to the core interpreter would be great but from an alternate implementation perspective I'd also be happy to see some wiggle room on small new features.

On Wed, Oct 21, 2009 at 3:07 PM, Dino Viehland <dinov@microsoft.com> wrote:
I don't think IronPython should support multiprocessing, personally. While there are a few things within it that probably make sense (managers and the like) does it really make a ton of sense to run multiple iron python VMs from a single parent? The same applies (in the case of multiprocessing) to Jython - a single JVM forking multiple JVMs doesn't necessarily make sense when you have perfectly functional threads. Then again, this depends on your perspective. When splitting out the stdlib was discussed at the language summit last year, this was discussed, and at the time a few people suggested allowing some stdlib modules to be marked at "cpython-only" - this means other implementations could omit/skip those modules (and not ship them). jesse

Jesse wrote:
The problem w/ this is that people are going to use multiprocessing and then someone is going to try running code which uses it on IronPython/Jython and it isn't going to work. So maybe we could have a version of multiprocessing that transparently works in a completely different fashion under the hood but it seems like the module should still exist and be usable.

On Wed, Oct 21, 2009 at 3:57 PM, Dino Viehland <dinov@microsoft.com> wrote:
I'm game, I just have reservations about doing this - something like multiprocessing that isn't multiprocessing means certain things/expectations applications might have could break in a dummy context. Since we're derailing, I'm game talking about this privately so we can pass ideas back and forth. jesse

2009/10/21 Dino Viehland <dinov@microsoft.com>
Was it a pain because it was on a builtin or because of the specific functionality? Michael

On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:
+1 to speeding up the gap-closing between 2.x and 3.x maturity and making the fielding of "When shoudl I start using 3.x?" questions easier. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

Nuts, I accidentally sent this just to Guido (again...) Sorry Guido! ------------------------------------- I, for one, am very glad to see this! I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed. I'd like to also point out that the import mechanism (including the concept of the python path, packages, and module initialization) seems to still be messy. For example, getting two copies of the same module when imported with and without a package prefix, and weird import ordering dependencies. I guess these would be covered under the "bugs in the language definition" above. I've wondered too about opening up the whole import process with more hooks to allow other notions of "compiling" and "loading" (for example, being able to import pickles of complex object networks that have been created through some other "compile" process that might still need file modification times checked, but with different file suffixes). This might help to give some degree of extensibility and support for domain specific languages, for example. I agree that Python will gain much more through better implementations than through further additions to the language. (And I don't mean to put down the CPython implementation in any way, it's carried us all a very long way!) Excluding the C implementation from the moratorium makes sense. +1 -Bruce On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:

On Wed, Oct 21, 2009 at 11:14 AM, Bruce Frederiksen <dangyogi@gmail.com> wrote:
I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed.
Depends on your definition of "bug". I would like to see this on a case-by-case basis.
Well, for better or for worse, changing that is *also* going to be messy and a compatibility nightmare. To some extent the details of the import mechanism is up to the implementation anyway, so this may not realistically be affected by the moratorium. If you want to discuss these issues in detail I recommend that you start a new thread and be prepared to hear "but that's just pilot error" about many of the perceived "bugs".
Actually, I think we already have enough import hooks, and this is an area where I would tread very carefully. There is nothing stopping people from using these mechanisms now, but still they are rarely used -- I don't expect that adding new types of hooks will change that.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 1:14 PM, Bruce Frederiksen <dangyogi@gmail.com>wrote:
I might suggest that changes to correct "bugs" in the language definition (and I don't just mean the documentation) should still be allowed.
I suggest allowing an exception for changes that make life *easier* for alternative implementations. That would allow for fixing "bugs", making small improvements to new features added in Python 3, etc. As long as it passes the test of making life easier for alternative implementations instead of more difficult. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

On Wed, Oct 21, 2009 at 11:45 AM, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
This is reasonable. We should discuss this at the Language Summit at the next PyCon. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 12:42 PM, Guido van Rossum <guido@python.org> wrote:
I can't disagree with the sentiment, and I wholeheartedly agree with the idea that shifting the focus from language development to library development is a good idea- but I would caution against making the moratorium too hard-and-fast, or too long lasting, assuming that the goal isn't to make it de facto permanent. Towards that end, I'd also like to propose a very public, very accessible 'sandbox' specifically for the development and testing of new language features while the moratorium is in effect. Its goal would be to keep interest in changes to core language design ongoing by keeping the barrier to entry low, while simultaneously separating it from core development. With any luck, it would mean that when the moratorium lifts, Python will be able to take its pick from the best of the language proposals, while still having given other implementations the opportunity to study their behavior "in the wild" for a period of months or years. Geremy Condra

On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <debatem1@gmail.com> wrote:
I can't stop people from forking the language to do experiments, but one of the goals I have for the moratorium is actually to *reduce* the interest in core language changes, and to *raise* the barrier to entry. Most language change proposals are just fluff, and they will be just as unneeded three years from now as they are today. Once the moratorium is lifted, users should be able expect the normal, slow, conservative evolution of the language to continue -- not to see the floodgates lifted for a barrage of new features. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Oct 21, 2009 at 3:02 PM, Guido van Rossum <guido@python.org> wrote:
Granted that most language change proposals could only be described as "terrible" by a person of unusual charity, but if the goal here isn't to permanently forbid all changes, then it makes sense (to me) to ensure that we're in a better position when we leave the moratorium than when we go into it. Right now, the barrier for proposing a language change is pretty much nonexistent- you dreamed it up in the shower, read about it in a trade magazine, your dog told you it was a good idea, doesn't matter- put it on python-ideas. The problem (as I see it) is that after proposing the idea, wasting a lot of time, and causing a lot of drama, the fact remains that even if the OP finally gets their way, the odds are good that it will take a substantial amount of work from people who have better things to do- the core developers- to make it work. And it only gets worse for the other implementors, who probably didn't have as much input in the process as the CPython devs did. Changing the way that core language changes are proposed and evaluated changes that a lot, though. In the scenario I've proposed, we are in effect saying "write the code and if it gets a lot of support we'll talk about including it in a few years". It shifts the responsibility for development from the core dev team to the one proposing the change. I'm confident that that alone would cut out most of the proposals on python-ideas, while ensuring that whatever was up for consideration at the point where the moratorium lifts was high-quality, well thought out code that had probably been looked at pretty closely by other implementors for several years. Personally, I think that's a much better place to be than either where we are now or where we'll be in a few years without some sort of brainstorm bin. Geremy Condra

On Thu, 22 Oct 2009 06:02:29 am Guido van Rossum wrote:
I was going to make a similar suggestion to Geremy, an official experimental branch in perpetual alpha, specifically to allow people to experiment with language changes. This doesn't mean that when the moratorium is lifted there will be a sudden flood of new features, radically changing the language: features will still need to go through precisely the same procedure to be accepted into the language as they do now. But it will be a place to point people and tell them "don't just tell us how you imagine this feature will work, show us". (For the record, I'm not suggesting that this experimental branch should be open to commits from anyone. You still have to convince those with privileges that your patch is worth looking at.) As far as the moratorium goes, I'm going to be the negative-nellie who says that I don't think this will actually make much practical difference. Python is, and always has been, very conservative about adding new language features. And so far, we've only heard from one developer of another Python implementation, Dino Viehland of IronPython, who said that language features are generally not a problem for him. As far as I can see, the only practical difference it will make is that it will cut short some (but not all) threads on python-ideas and comp.lang.python: anyone who suggests a language change will be told "Moratorium. Come back in 2013." This risks giving newbies the impression that Python is moribund and closed to new ideas -- not just the amateur language designers who have a wild and wacky ideas, but also those with clue who have good, thought-out ideas, as well as the quiet ones who don't have ideas but like those who do. Programming language popularity is not quite a zero-sum game, but languages do live or die by the ability to attract and keep new users. Particularly in Open Source languages, those users tend to be attracted more by "fresh and lively" than "stable and boring". So this is a cost that needs to be considered against the dubious (to me at least) proposition that a feature-freeze in the language will speed up uptake of 3.1. If library authors are going to support 3.x, they need to pick a minimum version and write for that. A new-feature freeze for 3.2 and 3.3 isn't going to make their life easier if they're writing for 3.1, for the obvious reason that they need to use only features available in 3.1. The only language changes that hurt them are non-backward compatible changes like the removal of features, but even there the benefit is minimal because Python already is very cautious about backwards compatibility. Features aren't removed or functionality changed without a long deprecation period, possibly even longer than the proposed moratorium. So I'm not convinced that this moratorium will actually give any advantage. -- Steven D'Aprano

On Thu, Oct 22, 2009 at 1:47 AM, Steven D'Aprano <steve@pearwood.info> wrote:
+1 for the sandbox idea. If crazy suggestions that come to python-ideas are plainly rejected because of the moratorium then I'm -1 on inventing discussion killers. If the moratorium PEP shows how a new language feature is to be introduced in an official sandbox etc, then I'm +1 for the moratorium. --yuv
participants (32)
-
Antoine Pitrou
-
average
-
Ben Finney
-
Brett Cannon
-
Bruce Frederiksen
-
Calvin Spealman
-
Christian Heimes
-
Collin Winter
-
Daniel Fetchinson
-
Daniel Stutzbach
-
Dino Viehland
-
Fred Drake
-
Georg Brandl
-
geremy condra
-
Gregory P. Smith
-
Guido van Rossum
-
Jared Grubb
-
Jesse Noller
-
Mathias Panzenböck
-
Michael Foord
-
Nick Coghlan
-
Oleg Broytman
-
Robert Kern
-
Ron Adam
-
Scott Dial
-
Stefan Behnel
-
Stephen J. Turnbull
-
Steven D'Aprano
-
Sturla Molden
-
Tim Peters
-
Xavier Ho
-
Yuvgoog Greenle