[Python-Dev] release plan for 2.5 ?

Raymond Hettinger raymond.hettinger at verizon.net
Fri Feb 10 22:05:35 CET 2006

[Guido van Rossum]
> 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?

It has at least one anti-champion.  I think it is a horrible idea and would 
like to see it rejected in a way that brings finality.  If needed, I can 
elaborate in a separate thread.

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

I helped tweak a few issues with the PEP and got added as a co-author.
I didn't push for it because the syntax is a little odd if nothing appears 
the while suite:

    val = source.read(1)
while val != lastitem:

I never found a way to improve this.  Dropping the final colon and 
steps improved the looks but diverged too far away from the rest of the 

    val = source.read(1)
while val != lastitem

So, unless another champion arises, putting this off until Py3k is fine with 

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

I installed the underlying mechanism in support of itertools.tee() in Py2.4.

So, if anyone really wants to make xrange() copyable, it is now a trivial 
task --
likewise for any other iterator that has a potentially copyable state.

I've yet to find a use case for it, so I never pushed for the rest of
the PEP to be implemented.  There's nothing wrong with the idea,
but there doesn't seem to be much interest.

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

I wouldn't hold-up Py2.5 for this.

My original idea for this was somewhat simpler.  Essentially, a high-level 
function would concatenate extra string information onto the result of an 
exception raised at a lower level.  That strategy was applied to an existing 
problem for type objects and has met with good success.

IOW, there is a simpler alternative on the table, but resolution won't take 
place until we collectively take interest in it again.  At this point, it 
seems to be low on everyone's priority list (including mine).


More information about the Python-Dev mailing list