Skip Montanaro wrote:
These various discussions are moving along a bit too rapidly for me to keep up. We have been discussing language issues which are going to impact Python 3.0, either by deprecating current language constructs which can't be eliminated until then (e.g., the global statement) or by tossing around language construct ideas which will have to wait until then for their implementation (other mechanisms for variable access in outer scopes). Unfortunately, I'm afraid these things are going to get lost in the sea of other python-dev topics and be forgotten about then the time is ripe.
The Summaries can help with this (this is why whenever an idea comes up for Py3k I try to mention it), but read below for worries on this.
Maybe this would be a good time to create a py3k@python.org mailing list with more restrictions than python-dev (posting by members only? membership by invitation?) so we can more easily separate these ideas from shorter term issues and keep track of them in a separate Mailman archive. I'd suggest starting a Wiki, but that seems a bit too "global". You can restrict Wiki mods in MoinMoin to users who are logged in, but I'm not sure you can restrict signups very well.
I am working on the next Summary and I am drowning here. Thanks to PEP 289 and PEP 323 I was able to basically do a quick overview and just point to the PEPs for generator expressions and reiterability/copying iterators, respectively. But I might have to summarize the 'global' discussion which is just immense. The problem is that I am the one doing the summary. Not only might I misunderstand something, but it will most likely have a slightly skewed view toward my thinking. I think Skip is right in having a separate place for *very* long-term discussions separate from immediate concerns. Long-term stuff does not need to be followed by everyone nor does everyone care about immediate issues like whether something should be backported. A layer of separation might be nice. Or perhaps a list for maintenance and another for new ideas. I can see having that division work as well. Dividing into more than two lists, though, would quickly turn into a logistical nightmare when ideas need to shift to another list. -Brett