Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Guido van Rossum <guido <at> python.org>
Subject: Py3k release schedule worries
Newsgroups: gmane.comp.python.python-3000.devel
Date: Monday 18th December 2006 23:39:51 UTC (over 10 years ago)
I am getting worried about the Py3k release schedule. According to PEP
3000, "I hope to have a first alpha release out sometime in 2007"
which would seem to give us another year at least; but in my mind I've
always interpreted this (and explained it to others) as "in the first
half of 2007" which would give us more like half a year at most.

With few exceptions, the discussions on the python-3000 list seem more
about radical redesign of the language than about the relatively
modest tweaks that I had in mind when I started the project. There
have been a few attempts at discussing a new string type that would be
Unicode-aware without always requiring storage for 4 bytes per
character, but AFAICT it fizzled; nobody has proposed to help with
getting the int unification branch, which is mostly done but still has
22 failing tests last time I looked. I've received a few contributions
to the bytes implementation (thanks Thomas!) and Tomer has made
valiant attempts to help with the redesign of the I/O library (for
which my apologies for not providing enough feedback).

My general impression is that the majority of the participants on the
list are more interested in free-for-all language design discussions
than in getting things done. As a symptom, I received very few
responses to my announcement of a refactoring tool; the ones that I
got were more of a theoretical nature "maybe look at this alternative
approach" rather than "how can I help" or "here's a refactoring I
wrote using your tool and here's a suggestion for how you can make it
easier to write such refactorings".

I do realize that I have quite a bit of responsibility myself. Some of
you may have seen the Google video about my internal Google project
("Mondrian") -- this has been a really fun project, but also quite
time consuming, and I've definitely spent less than 50% of my time on
Python over the past 6 months; especially the time from September
through November felt like I had no time to work on Python (my own
choice, largely, in order to accomplish some aggressive goals for
Mondrian's roll-out to all of Google). And when I recently had a whole
day to spend on Py3k, I foolishly engaged in a discussion about
interfaces and generic functions.

But I'm going to mend my ways. Think of this email as an early new
year's resolution (and not of the kind that fizzles within a week).

I currently have over 60 threads in my inbox with "python-3000" in the
subject that I haven't read, or haven't read completely, the oldest
one dating back to April. Clearly I'm not ever going to be able to
catch up on all those discussions, and the wisest thing for me to do
would probably to just delete (well, archive -- after all I'm using
Gmail :-) those threads and start over. Or maybe at least archive
everything older than a week (that would leave only 8 threads -- still
about 180 messages!).

I want to change the general mood in the python-3000 list to one that
is more conducive to getting things done and meeting a schedule. If we
aim for an alpha in June 2007, and the schedule slips (as it always
will), no harm is done. If we aimed for December, however, slippage
would be more serious (since the PEP currently says 2007).

If we want to have an alpha by June 2007, we should aim to have the
last PEP in by April. I propose that all discussions on the
python-3000 list should strive to produce a PEP. This doesn't get rid
of all radical redesign, but it at least sets the bar higher -- a PEP
needs to be specified to a very high level of detail, and that means
that discussions where nobody is interested in doing that work will
automatically be cut short.

Perhaps we can create a python-4000 list for folks who would like to
discuss changes to the language beyond Python 3.0 -- I'm not opposed
to having an outlet for such discussions, I just believe that we've
come to a point where they are endangering the project's chances of
ever actually reaching a milestone at all. (It seems that some
participants have forgotten the mantra "Not Perl Six." :-)

I'd also like to set some specific goals for some of the major tasks.

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

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.

Finally, what will I do myself? Apart from redirecting certain kinds
of ideas to the python-4000 list, I will take upon me a lot of the
implementation work, and a lot of the PEP writing. But even if I do
use my 50% Python time to the fullest for this purpose, I will need a
lot of help. And if you leave the string unification to me, I will
just rip out the 8-bit string object in favor of the existing Unicode
implementation. So please help!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
 
CD: 4ms