[Python-3000] Py3k release schedule worries

Thomas Wouters thomas at python.org
Tue Dec 19 01:33:14 CET 2006

On 12/18/06, Guido van Rossum <guido at python.org> wrote:
> I am getting worried about the Py3k release schedule.

Hah, only now? I've been worried every time I archive 20-unread-message
conversations in the python-3000 list -- which it feels like I've been doing
every two days for months :)

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.

Me, I'm all for implementing stuff. I'll happily implement physically
possible, somewhat-fleshed-out ideas anyone brings up -- regardless of
python-3000's prevaling opinion. I'm really not for all the yakking,
especially not the ideas that seem to be relevant only to very specific
cases -- but then, I really don't care how easily Python code could be used
as a DSL. I just want Python, and for Python to be Python. If that means
special cases have to look uglier or be harder, too bad.

As you may be aware, I'm finishing up the slice-removal that I was working
on at the Python sprint. Parts of it will be going into the trunk (patches
all submitted, reviews welcome), and when I merge them into the p3yk branch,
I'll submit the rest for p3yk inclusion. After that, I was thinking of
working on the 'super' improvements that have been suggested, or removing
list comprehensions as separate construct (and cleaning up the grammar and
code generator to boot). I don't care for the pre-select-metaclass idea (I
see no point in it, except for the DSL thing I think is harmful to generic
Python), nor for generic functions or complicated solve-world-hunger ABCs or
interfaces -- or anything else that's needlessly complicated. I haven't
decided yet whether the new I/O system or the 'low-storage unicode' ideas
fall under those categories :)

However, I can pick up string formatting if no one else does, or help with
the int/long unification. I should have more than enough time for all of
those well before PyCon, or at PyCon -- it's not like they're really
challenging; string formatting is easy, int/long unification is mostly done
by Martin.

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.

I'm afraid that this problem just needs a decision: How do you (Guido, not
python-3000) want to organize the standard library?  Maybe you already made
that decision and it was in one of the threads I never read -- if so, sorry
Anyway, there's lots to be said for all approaches to organizing the
standard library, so I think you should just decide between java-like
(deeply structured), the current (unstructured, but with modules renamed to
fit styleguide, possibly with a 'stdlib' package covering all) or inbetween.
I favour second option without package; the other two options will no doubt
generate much discussion about how deep the structure should be and what
categories it should cover. I'd rather spend time renaming modules than
archiving threads :-)

Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061218/1ace79f0/attachment.html 

More information about the Python-3000 mailing list