[Python-Dev] Time for py3k@python.org or a Py3K Wiki?

Brett C. bac at OCF.Berkeley.EDU
Sat Nov 8 19:11:23 EST 2003

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


More information about the Python-Dev mailing list