[Python-Dev] release plan for 2.5 ?

[Guido van Rossum]

On 2/7/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
> On 2/7/06, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
> > It looks like we need a Python 2.5 Release Schedule PEP.
>
> Very draft: http://www.python.org/peps/pep-0356.html
>
> Needs lots of work and release managers.  Anthony, Martin, Fred, Sean
> are all mentioned with TBDs and question marks.

Before he went off to a boondoggle^Woff-site at a Mexican resort, Neal
made me promise that I'd look at this and try to get the 2.5 release
plan going for real.

First things first: we need a release manager. Anthony, do you want to
do the honors again, or are you ready for retirement?

Next, the schedule. Neal's draft of the schedule has us releasing 2.5
in October. That feels late -- nearly two years after 2.4 (which was
released on Nov 30, 2004). Do people think it's reasonable to strive
for a more aggressive (by a month) schedule, like this:

    alpha 1: May 2006
    alpha 2: June 2006
    beta 1:  July 2006
    beta 2:  August 2006
    rc 1:    September 2006
    final:   September 2006

??? Would anyone want to be even more aggressive (e.g. alpha 1 right
after PyCon???). We could always do three alphas.

There's a bunch of sections (some very long) towards the end of the
PEP of questionable use; Neal just copied these from the 2.4 release
schedule (PEP 320):

- Ongoing tasks
- Carryover features from Python 2.4
- Carryover features from Python 2.3 (!)

Can someone go over these and suggest which we should keep, which we
should drop? (I may do this later, but I have other priorities below.)

Then, the list of features that ought to be in 2.5. Quoting Neal's draft:

>    PEP 308: Conditional Expressions

Definitely. Don't we have a volunteer doing this now?

>    PEP 328: Absolute/Relative Imports

Yes, please.

>    PEP 343: The "with" Statement

Didn't Michael Hudson have a patch?

>    PEP 352: Required Superclass for Exceptions

I believe this is pretty much non-controversial; it's a much weaker
version of PEP 348 which was rightfully rejected for being too
radical. I've tweaked some text in this PEP and approved it. Now we
need to make it happen. It might be quite a tricky thing, since
Exception is currently implemented in C as a classic class. If Brett
wants to sprint on this at PyCon I'm there to help (Mon/Tue only).
Fortunately we have MWH's patch 1104669 as a starting point.

>    PEP 353: Using ssize_t as the index type

Neal tells me that this is in progress in a branch, but that the code
is not yet flawless (tons of warnings etc.). Martin, can you tell us
more? When do you expect this to land? Maybe aggressively merging into
the HEAD and then releasing it as alpha would be a good way to shake
out the final issues???

Other PEPs I'd like comment on:

PEP 357 (__index__): the patch isn't on SF yet, but otherwise I'm all
for this, and I'd like to accept it ASAP to get it in 2.5. It doesn't
look like it'll cause any problems.

PEP 314 (metadata v1.1): this is marked as completed, but there's a
newer PEP available: PEP 334 (metadata v1.2). That PEP has 2.5 as its
target date. Shouldn't we implement it? (This is a topic that I
haven't followed closely.) There's also the question whether 314
should be marked final. Andrew or Richard?

PEP 355 (path module): I still haven't reviewed this, because I'm -0
on adding what appears to me duplicate functionality. But if there's a
consensus building perhaps it should be allowed to go forward (and
then I *will* review it carefully).

I found a few more PEPs slated for 2.5 but that haven't seen much action lately:

PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of
freezing arbitrary mutable data structures. Are there champions who
want to argue this?

PEP 349 - str() may return unicode. Where is this? I'm not at all sure
the PEP is ready. it would probably be a lot of work to make this work
everywhere in the C code, not to mention the stdlib .py code. Perhaps
this should be targeted for 2.6 instead? The consequences seem
potentially huge.

PEP 315 - do while. A simple enough syntax proposal, albeit one
introducing a new keyword (which I'm fine with). I kind of like it but
it doesn't strike me as super important -- if we put this off until
Py3k I'd be fine with that too. Opinions? Champions?

Ouch, a grep produced tons more. Quick rundown:

PEP 246 - adaptation. I'm still as lukewarm as ever; it needs
interfaces, promises to cause a paradigm shift, and the global map
worries me.

PEP 323 - copyable iterators. Seems stalled. Alex, do you care?

PEP 332 - byte vectors. Looks incomplete. Put off until 2.6?

PEP 337 - logging in the stdlib. What of it? This seems a good idea
but potentially disruptive (because backwards incompatible). Also it
could be done piecemeal on an opportunistic basis. Any volunteers?

PEP 338 - support -m for modules in packages. I believe Nick Coghlan
is close to implementing this. I'm fine with accepting it.

PEP 344 - exception chaining. There are deep problems with this due to
circularities; perhaps we should drop this, or revisit it for Py3k.

That's the "pep parade" for now. It would be appropriate to start a
new topic to discuss specific PEPs; a response to this thread
referencing the new thread would be appropriate.

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