Raymond Hettinger <[EMAIL PROTECTED]> writes: > In Py2.6, I will mostly likely put in an automatic promotion to long > for both enumerate() and count(). It took a while to figure-out how > to do this without killing the performance for normal cases (ones used > in real programs, not examples contrived to say, "omg, see what > *could* happen").
Great, this is good to hear. I think it's ok if the enumeration slows down after fixnum overflow is reached. So it's just a matter of replacing the overflow signal with consing up a long. The fixnum case would be the same as it is now. To be fancy, the count could be stored in two C ints (or a gcc long long) so it would go up to 64 bits but I don't think it's worth it, especially for itertools.count which should be able to take arbitrary (i.e. larger than 64 bits) initializers. As for real programs, well, the Y2038 bug is slowly creeping up on us. That's when Unix timestamps overflow a signed 32-bit counter. It's already caused an actual system failure, in 2006: http://worsethanfailure.com/Articles/The_Harbinger_of_the_Epoch_.aspx Really, the whole idea of int/long unification is so we can stop worrying about "omg, that could happen". We want to write programs without special consideration or "omg" about those possibilities, and still have them keep working smoothly if that DOES happen. Just about all of us these days have 100's of GB's or more of disk space on our systems, and files with over 2**32 bytes or lines are not even slightly unreasonable. We shouldn't have to write special generators to deal with them, the library should instead just do the right thing. -- http://mail.python.org/mailman/listinfo/python-list
