On Wed, Oct 21, 2009 at 2:06 PM, Guido van Rossum <guido@python.org> wrote:

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.

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.

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.

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

On Wed, Oct 21, 2009 at 11:24 AM, Georg Brandl <g.brandl@gmx.net> wrote:

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... :)

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.

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 think fixing ambiguous corner cases can proceed.

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.

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/)

On Wed, Oct 21, 2009 at 3:07 PM, Dino Viehland <dinov@microsoft.com> wrote:

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.

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

On Wed, Oct 21, 2009 at 3:57 PM, Dino Viehland <dinov@microsoft.com> wrote:

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

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

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 3:02 PM, Guido van Rossum <guido@python.org> wrote:

On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <debatem1@gmail.com> wrote:

...

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.

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/)

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, Oct 22, 2009 at 1:47 AM, Steven D'Aprano <steve@pearwood.info> wrote:

On Thu, 22 Oct 2009 06:02:29 am Guido van Rossum wrote:

...

On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <debatem1@gmail.com> wrote:

...

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. ... I was going to make a similar suggestion to Geremy, an official experimental branch in perpetual alpha, ...

+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:

Yuvgoog Greenle writes:

 > official sandbox

That's an oxymoron, IMHO.

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

On 21 Oct 2009, at 16:47, Steven D'Aprano wrote:

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

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 8:31 PM, Guido van Rossum <guido@python.org> wrote:

On Thu, Oct 22, 2009 at 5:15 PM, Jared Grubb <jared.grubb@gmail.com> 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).

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.

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.

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.

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 9:07 PM, Guido van Rossum <guido@python.org> wrote:

On Thu, Oct 22, 2009 at 5:57 PM, geremy condra <debatem1@gmail.com> wrote:

...

On Thu, Oct 22, 2009 at 8:31 PM, Guido van Rossum <guido@python.org> wrote:

...

On Thu, Oct 22, 2009 at 5:15 PM, Jared Grubb <jared.grubb@gmail.com> 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).

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.

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.

Actually removing the GIL is not subject to the moratorium, and it seems that some people *are* working on code.

Alright then, adding default arguments that evaluate when the function is called.

...

...

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.

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.

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. :-)

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 11:38 PM, Guido van Rossum <guido@python.org> wrote:

On Thu, Oct 22, 2009 at 8:04 PM, geremy condra <debatem1@gmail.com> wrote:

...

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.

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/)

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 11:50 PM, Guido van Rossum <guido@python.org> wrote:

On Thu, Oct 22, 2009 at 8:45 PM, geremy condra <debatem1@gmail.com> 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.

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/)

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 Fri, Oct 23, 2009 at 5:50 AM, Guido van Rossum <guido@python.org> wrote:

You keep stressing the opportunities for new features, but I want to crush that hope [ snip ] Go invent a new language (and hope for it to become popular :-) if you want to experiment.

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

On Fri, Oct 23, 2009 at 11:30 AM, Guido van Rossum <guido@python.org> wrote:

Let's wait for the PEP before derailing this discussion any more.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

I'm crossing my fingers to crank on it this weekend. Sorry for the delay jesse

On Fri, Oct 23, 2009 at 11:45 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Bruce Frederiksen wrote:

...

OK, I'm an outsider here.  But looking at this whole discussion a picture emerges.  So I'll toss this out here for discussion (and I'm really going out on a limb here, but it's OK to shoot the outsider!)

"I propose a moratorium on language changes. This would be a period of several years during which no changes to Python's grammar or language semantics will be accepted. The reason is that frequent changes to the language cause pain for implementors of alternate implementations..."

What I see happening is a realization as we move into 2010 that the C language is no longer the future.  We may not know yet what language is the future.  And we might imagine that it ought to be Python.  This discussion is being done within the CPython group.  That has two parts: C and Python.  I see the moratorium as a declaration that Python needs a new implementation.  It needs a new horse to ride on.

I don't believe this is an accurate characterisation of the situation (neither in regards to the state of C, nor in regards to the state of Python).

Agreed.

C isn't going anywhere - it is still massively important as a portable language that can be made to run pretty much anywhere with minimal application overhead relative to raw assembler (and often faster than hand-coded assembler, since humans aren't smart enough to manually optimise code for many modern processors). Developers of new platforms don't need to tediously hand code lots of tools - they just need to teach a C compiler to generate code for their platform and the bootstrapping process gets off to a flying start.

However, C retains that relevance without the core language changing very much - the last major update was C99, and the update before that was C89, which was itself a consolidation of assorted features introduced by various alternative implementations since K&R C was documented in 1978. Some would even say that it is the very simplicity and stability of C that has lead to its ubiquity.

Importantly, while Python is not Java, Python is also not C. The analogy between Python's life cycle and that of a language that was designed entirely in-house and before the words "internet" or "open source" were coined is at best flawed and at worst dangerously misleading. I would point instead to the development of a language like PHP as the more accurate metaphor- and despite its syntax and core language changes, it remains more popular than Python.

So that's 2 language updates in more than 30 years since a C language spec was first articulated. Python has had more major updates than that in barely half the time. Now, for a long time, that didn't really matter because only the reference interpreter saw serious use. Stackless was around, but able to pick up most changes directly from the reference implementation (since it only modified the VM and was able to retain most of the rest of the core C code), while Jython fell by the wayside for a while when new style objects were introduced in Python 2.2.

The situation now is significantly different. There are at least 3 major Python implementations under active development and in production use that I know of (CPython, Jython, IronPython), other major implementations that, if not in production use yet, will be eventually (e.g. PyPy, Unladen Swallow) and various other tools based around existing Python syntax (Pyrex, Cython).

Changes to the core language spec now affect a *lot* more than just CPython - there are ripple effects that spread out through the whole language ecosystem. On the other hand, standard library changes to modules that other Python implementations are able to use without modification don't generally have anywhere near the same impact.

Granted, and this is why I support the moratorium. However, I also support eventually *lifting* the moratorium- Python competes more against today's highly dynamic languages than yesterday's quite static languages. Stand too still for too long and we risk standing nowhere at all.

Guido's proposed moratorium is a formal recognition of the fact that tinkering with the underlying language isn't what Python really needs right now. It *is* possible for a language to become "feature complete" from a practical point of view, after which tinkering at the edges and introducing special syntax for niche use cases becomes a distraction from more productive endeavours.

And I agree that it isn't what Python needs *right now*. But that is totally different from saying that there simply aren't any good ideas left. We should give those ideas an opportunity to be heard so that in a few years when everybody is caught up we stand in a position to make good, well-informed decisions about what the language needs.

We changed a lot of things in Py3k - by saying "no, we aren't going to change anything else in the core language spec for at least the next few years" we would be consciously taking a step back and waiting to see how all those changes play out in the real world before we start trying to build on them.

Agreed.

We would be giving the alternative implementations a chance to come up to speed with their own Python 3.x implementations, giving major applications and frameworks a chance to do forward ports without difficult decisions as to which version to target and giving users a chance to get used to a new feature set before throwing yet more deltas at them (e.g. I don't think anyone has even begun to scratch the surface of the power and flexibility provided by PEP 3115).

Agreed.

Are language changes going to be completely impossible under such a moratorium? Of course they aren't - if a solid enough case is made for a change, then we aren't going to dig our heels in just because we made a formal statement that we didn't want to change certain things for the next few years. If somebody comes up with a language improvement that is as groundbreaking as the with statement was for Python, or as asynchronous blocks would be for C, then of course we would still give it serious consideration.

Actually, that's almost exactly the opposite of what Guido said- that there will be no one-change exceptions.

However, even a cursory glance at Python ideas shows that most current suggestions for tweaks to the core language don't really measure up to that standard. Even PEP 380 (generator delegation), which is a decent, well thought out suggestion, has to rely fairly heavily on language consistency and coherency arguments because the real world use cases that can't already be handled a different way are fairly minimal.

Arguments against past proposals are not arguments against future proposals. Unless Guido's time machine got an extra supercollider while I wasn't looking, nobody on this board knows what's coming down the pipe next, and my argument is that if the suggestion is super-awesome, popularly supported, and maintained until the end of the moratorium, then it should have a really good chance of getting in. To paraphrase a discussion I had on this topic last night, the fact that there's a long, hard road to getting a feature into the language isn't a problem. The idea that there shouldn't be a road is. Geremy Condra

2009/10/23 Guido van Rossum <guido@python.org>

On Fri, Oct 23, 2009 at 9:18 AM, geremy condra <debatem1@gmail.com> wrote:

...

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.

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.

Despite the title this was never really a 'proposal' was it. ;-) All the best, Michael

-- --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/> ) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- http://www.ironpythoninaction.com/

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.

Scott Dial writes:

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

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.

geremy condra wrote:

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.

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

geremy condra wrote:

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.

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:

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.

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 <guido@...> writes:

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?

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.

On Sun, Oct 25, 2009 at 2:18 PM, Georg Brandl <g.brandl@gmx.net> wrote:

Antoine Pitrou schrieb:

...

Guido van Rossum <guido@...> writes:

...

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?

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.

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.

<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 3:01 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

geremy condra wrote:

...

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.

Having an "official sandbox" is completely irrelevant (and probably counterproductive) if core development is happening in a DVCS.

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.

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.

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.

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.

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.

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.

That's the goal, I'd just also like to have all those improvements centralized for easy review and comparison. Geremy Condra

On Sun, Oct 25, 2009 at 11:28 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

geremy condra writes:

 > > Having an "official sandbox" is completely irrelevant (and probably  > > counterproductive) if core development is happening in a DVCS.  >  > I don't see any evidence for either of these claims,

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.

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.

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

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.

There is an enormous risk that they are wasting their time. The goal is to save the core devs' time, not those proposing features.

 > 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,

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.

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.

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

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

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.

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.

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

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

On Mon, Oct 26, 2009 at 2:12 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

geremy condra writes:

 > There is an enormous risk that they are wasting their time.  The  > goal [of a sandbox] is to save the core devs' time, not those  > proposing features.

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.

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.

I've already addressed that, see the messages you reference.

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.

Nope, not the goal.

 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.

No, it wouldn't. Because that's not the point.

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

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

Are you sure you're not confusing it with the distutils thread(s)?

Pretty sure.

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

But those are precisely the people whose time you plan to save.

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.

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

Yup.  Precisely the kind of stuff that happens in real projects, not in sandboxes.

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.

 > > 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.  >  > I doubt this. Experience suggests that the number of individuals  > proposing changes with the technical chops to pull them off is  > relatively small,

Sure, but they generally also are core developers.  I don't see why an "official sandbox" will be of use to them.

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

On Tue, Oct 27, 2009 at 8:49 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

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

 > Don't assume that the only people with the experience and knowledge  > to implement [a language change] are part of the core dev group-  > especially a couple of years from now.

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.

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

On Sun, Oct 25, 2009 at 4:34 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

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

 > 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

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

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 Sun, Oct 25, 2009 at 4:22 PM, Steven D'Aprano <steve@pearwood.info> wrote:

On Sat, 24 Oct 2009 04:30:36 pm Stephen J. Turnbull wrote:

...

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

I argue that you've got it backwards. [...]

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.

geremy condra wrote:

On Sun, Oct 25, 2009 at 8:51 PM, Guido van Rossum <guido@python.org> wrote:

<snip>

...

Also to stop the pointless discussions about anonymous blocks (though that may have been naive :-).

-- --Guido van Rossum

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.

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

Guido van Rossum writes:

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

By Clarke's Law, I see no way to distinguish between the presence and the absence of intelligent design in nature.

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.

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:

Guido van Rossum writes:

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

By Clarke's Law, I see no way to distinguish between the presence and the absence of intelligent design in nature.

So using Occam's razor we might as well assume there is none.

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

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

But hard to answer. Have faith. :-)

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.

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.

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>

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.

Guido van Rossum wrote:

On Wed, Oct 21, 2009 at 11:52 AM, geremy condra <debatem1@gmail.com> wrote:

...

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.

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.

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 Wed, Oct 21, 2009 at 1:52 PM, geremy condra <debatem1@gmail.com> wrote:

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.

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>

On Wed, Oct 21, 2009 at 13:20, Mathias Panzenböck < grosser.meister.morti@gmx.net> wrote:

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.

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

Brett Cannon schrieb:

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

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

That's a looong time (for me at least), but still an acceptable timeframe.

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

The moratorium should also give us time and space to focus on bug fixes for the language which is good.

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.

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

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

+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 Wed, Oct 21, 2009 at 7:18 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Brett Cannon <brett@...> writes:

...

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.

Time-based releases can be good, but 18 months until the feature freeze (which, realistically, gives us a new release every 2 years) sounds much too long to me.

Regards

Antoine.

+1 18 months seems too long.

On Wed, Oct 21, 2009 at 4:24 PM, Brett Cannon <brett@python.org> wrote:

On Wed, Oct 21, 2009 at 09:42, Guido van Rossum <guido@python.org> wrote:

...

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

+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 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.)

The moratorium should also give us time and space to focus on bug fixes for the language which is good.

...

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.

Sounds reasonable to me.

...

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

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 =).

I second this- especially if it includes a code-first requirement.

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

Ditto.

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

Sounds good to me. Geremy Condra

On Wed, Oct 21, 2009 at 1:28 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

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)

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/)

Antoine Pitrou wrote:

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.

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

On Thu, Oct 22, 2009 at 11:40 AM, Tim Peters <tim.peters@gmail.com> wrote:

[Guido]

...

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.

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.

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

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.

Ah, you've moved from fractional winks to fractional votes. A nice upgrade. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Thu, Oct 22, 2009 at 12:48 PM, Robert Kern <robert.kern@gmail.com> 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.

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/)

On Thu, Oct 22, 2009 at 11:40 AM, Tim Peters <tim.peters@gmail.com> wrote:

[Guido]

...

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.

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.

+1.1 from me. Someone's gotta pick up Tim's 0.1 slack. ;)