Guido sent an email to python-3000 saying he was a little worried about the schedule for Py3K. He has now given a rough timeframe in PEP 3000. It looks like we should have an alpha around mid-2007 with final release about a year after that. He is also planning to have a cut-off date for Python 3000 PEPs at the end of April 2007.
In his email Guido also pulled the reins in on all of the language design topics and move it more towards getting Python 3.0 to come to fruition. Part of this includes creating an ideas list to have nebulous ideas to be discussed. This would allow python-3000 and python-dev to focus more on dev work and discussing submitted PEPs while the ideas list would be more for nebulous ideas like what has been hitting python-3000 lately. The list has not been created yet, though, and at least effbot does not like the idea of the list. We will see if it happens.
Guido then listed off what he needs help getting done. He wanted PEPs on abstract base classes, unification of string and unicode, views for collections for dict.keys() et. al., optional signature annotations, and a new I/O library. And in terms of stuff that is already solidified, beyond PEP 3100 there is also the int/long unification (which Martin v. Loewis has started by has 22 failing tests still), new string formatting (of which there is a Python implementation), and helping with Guido's refactoring tool and providing refactoring rules. And the nice, contentious issue of the stdlib reorg is yet to be dealt with.
As for my part in all of this, I have PEP 352 and PEP 362 to deal with. Guido also said he hopes my import rewrite ends up as the import implementation in Python 3000.
I also have three PEPs I plan to write. One is the stdlib reorg. I have tried to get this to happen several times before but I wanted too big of a change for it to move forward. But Guido pronounced that there should be removal of "silly old stuff", renaming where the module does not follow PEP 8, and to eliminate the whole C/Python dichotomy for things like pickle/cPickle. That helps keep things within reason. Modules that need major renaming are to be done as separate PEPs.
The second thing is slight changes to the import machinery. I would like to push more things into being their own importers. I would also eliminate the notion of a default importer when sys.path_importer_cache has None for a path value. Lastly I would like to change the call signature of __import__ to be ``module_name, callers_name, path, from, level``. That eliminates automatically passing globals and locals to the function and instead specifies what is truly important for importing. It also renames some arguments. Nothing drastic, just a tightening of the API. Maybe even remove the whole 'level' argument and let __import__ deduce that on its own instead of the compiler.
As for the third thing, it is something I have discussed before that some old-timers don't want to see removed. But considering most people in the real world don't even know about it I think they are a vocal minority. I am going to have a lightning talk on this PEP idea at PyCon where I poll the audience on whether they knew something was possible (and to make sure people are honest I am not mentioning what it is specifically here). Hopefully my reasoning behind it is sound (which Guido has personally told me he thinks it is) and so it can happen.
Anyway, it is nice seeing that there is a light at the end of the tunnel. Of course all of this is coming when I am supposed to be working towards a more solid thesis topic and thus will be more busy now than I have been. Oh well, luckily my girlfriend is understanding when I want to spend a weekend coding. =)
