[Python-3000] Py3k release schedule worries

[Brett Cannon]

On 12/18/06, Guido van Rossum <guido at python.org> wrote:
>
> 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.


I always wondered about that due date and when you really wanted to cut an
alpha.

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.


Oh yeah.

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 think another big reason, though, is people are taking the view of Py3k
really far in terms of it being a clean slate.  I have always viewd Python
3.0 as Python 2.x cleaned up.  That leaves Python 3.whatever for new
additions.  But I think a lot of people have skipped past the goal of
getting a cleaned-up Python 3.0 and made that the whiz-bang version.

I know the reason I didn't jump in on the refactoring tool is that a) I was
wondering how Jeremy's tool fit into all of this (if at all), b) I am busy
with the import rewrite, c) my laptop is *still* in the shop and thus I
can't hack at home, and d) it doesn't interest me as much as other things I
want to do for Py3K.

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


Yeah, the Py3K threads tend to grow rather quickly.

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


A Python pie-in-the-sky list (python-ideas?) seems reasonable.  Let's
python-dev focus on maintaining the current code, python-3000 on
Py3K-specific work, and the ideas list to be where new ideas are vetted out
and congealed into a PEP to bring to either python-3000 or python-dev.

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


I have been thinking about this one, especially after the discussions of the
patch floating around that has an initial implementation.  I was planning on
tackling this at some point so it was nice and simple (just store strings
instead of actual types so it truly just documentation initially) and tied
into my signature PEP.

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


Well, I have tried to move this forward before and it always just leads to a
huge explosion of ideas and feelings and just doesn't get anywhere.  I am
willing to be the guy to don the flame suit once again on this topic and try
to get this PEP written for strategy for renaming, reorganizing, and
deprecating modules.

But I will probably need some general guidance from what you are looking for
in terms of scope (e.g., if I remember correctly you don't want a 'py'
top-level namespace and you didn't like the idea of having like a 'net'
package, etc.) and depth (does the renaming extend to methods?).

I am definitely willing to commit to PEP 352 (new-style exceptions) and PEP
362 (signature PEP, but still needs a pronouncement).  After that I am up
for helping with the library re-org and probably with the type annotations
stuff.  I am considering my import work as implementation-specific and thus
can go in at almost any point (assuming backwards-compatibility issues are
not considered too horrible or performance is within reason) and thus not
necessarily time critical (unless you want to force it into Py3K to specify
"new" semantics), in which case I would shift that up in priority.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061218/7b0b7e36/attachment-0001.htm