[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.
-Brett
More information about the Python-Dev
mailing list