[Python-Dev] release plan for 2.5 ? (original) (raw)

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

More information about the Python-Dev mailing list