enumerate overflow

[Paul Rubin]

Raymond Hettinger <python at rcn.com> 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.