On 2/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 2/7/06, Jeremy Hylton <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com