[Python-3000] Py3k release schedule worries (original) (raw)

Brett Cannon brett at python.org
Tue Dec 19 01:53:55 CET 2006

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.

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

More information about the Python-3000 mailing list