[Python-3000] Py3k release schedule worries

[Georg Brandl]

Guido van Rossum schrieb:

[snip... full ACK]

> For example, there are some PEPs that I'd like to see written where
> the basic goal has been firmly established but the details need
> working out:
> 
> - a collection of ABCs to be used with the standard types; see Bill
> Janssen's wiki page
> - optional signature annotations (but without type checking
> connotations); e.g. ``def foo(a: 42) -> "hello kitty": pass'' should
> be fine; see my Artima blogs
> - make keys(), items(), values() return pseudo-sets/collections rather
> than lists
> - a spec for the new I/O library (building on Bill Janssen's wiki and
> Tomer's work)
> - a spec for the string unification (Perhaps Fredrik has done some
> work on it in one of those threads that I haven't opened yet?)
> 
> I'd also like to see people volunteer to help with the implementation
> of some of these projects, and with the implementation of projects
> that already have a PEP or don't need one. For example:
> 
> - the new string formatting (s.format(a1, a2, ...))
> - finishing the int unification branch
> - contributing refactorings
> - turning list comprehensions into syntactic sugar for generator expressions

I'd like to point out that there is already my patch for that, which implements
set comprehensions and list comprehensions exactly as syntactic sugar for
GEs. This, however, affects performance greatly as LCs are executed in their own
function scope, which isn't necessary. A better implementation would therefore
leave the LC implementation as is, only preventing the name leaking into the
enclosing scope.

> - implement refactorings that convert many of the changes listed in PEP 3000
> 
> For more inspiration, see the long list of proposed changes in PEP
> 3100. (But do pick the hard ones first -- I'm not worried about the
> simple ones, and some of the simple ones are even controversial, e.g.
> moving id or intern, or removing find/rfind).

Oh, bad luck for me. I had intended to go over more of the easier ones
and implement them...

so what about id() and intern(). Care to pronounce?

> Perhaps the most controversial issue that I'd like to tackle is a
> standard library reorganization. This is so controversial that I don't
> even know where to begin. Maybe the refactoring tool will be able to
> help and can automatically convert imports using old locations to
> imports using new locations? Then if the new locations are also made
> available in Python 2.6, we'd even have an upgrade path. Who wants to
> help out here? There's a huge amount of work and if it is left to me
> it won't get done.

Aside from reorganization, a large thing would be improvement of existing
modules in the inside (see PEP 3001). I know some people who'd like to help
by e.g. making legacy modules PEP 8 compatible. Would that be accepted,
or is it too low-priority to care?

cheers,
Georg