[Python-Dev] release plan for 2.5 ?
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
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