Barry A. Warsaw writes:
Guido> There are several other things I can think of now that were Guido> planned for 1.6: revamped import, rich comparisons, revised Guido> coercions, parallel for loop (for i in L; j in M: ...), Guido> extended slicing for all sequences.
I'm not clear on the status of these various things; how many of these changes are deep ones that need lots of design, or affect massive amounts of the code base? For example, revamped import is a tricky design problem (as we've seen on this list). Is the spec for rich comparisons clearly defined at this point? Something like the parallel for loop seems like a parser modification combined with a code-generator modification, with no subtle implications for the rest of the implementation, and so that seems a simple matter of programming -- a week or so of effort. (Maybe I've missed something?)
Guido> I've also been Guido> thinking about making classes be types (not as huge a Guido> change as you think, if you don't allow subclassing Guido> built-in types), and adding a built-in array type suitable Guido> for use by NumPy. I've also received a conservative GC Guido> patch that seems to be fairly easy to apply and has some of Guido> Tim Peters' blessing.
Similarly, does the conservative GC patch splatter changes all over the place, or is it very localized? Is adding the NumPy array type straightforward? Remember, there would presumably be a couple of 1.6 alphas and betas to shake out bugs.
From a political standpoint, I'd call the next release 1.6 and not bother with another installment in 1.5.x series. And I agree with
Fair enough; forget about the 1.5.5 suggestion, and call it as 1.6.
tree. My free-time plate is pretty full with JPython and Mailman, but I'm willing to help where possible.
Ditto. -- A.M. Kuchling http://starship.python.net/crew/amk/ One trouble with being efficient is that it makes everybody hate you so. -- Bob Edwards, the Calgary Eyeopener, March 18, 1916