[Python-Dev] release plan for 2.5 ?

[Raymond Hettinger]

[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 
in
the while suite:

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

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

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

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



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



Raymond