[Python-Dev] Re: Proposed iterator representations

Raymond Hettinger python at rcn.com
Fri Apr 9 18:06:38 EDT 2004


[David Eppstein]
> Speaking of itertools.count, where can I find the rationale for the
> "Does not currently support python long integers." restriction?

The rationale was writing "the simplest thing that could possibly work".
At the time, there were no use cases that warranted additional code
complexity.  I wanted this to be bug free right out of the box.  In the
docs, I included a cut and pastable pure python version that did support
long integers so that no one would be left in the cold.  As you said,
rolling your own is trivial.

Also, the design was also affected by trying to fit itertools.count()
into the tiny ecological niche between xrange() and itertools.repeat().
Its competitive advantage was being lightweight, fast, and infinite so
you could write things like izip(count(10), data).


Raymond


"... as a general rule of thumb, the first time a memory location is
accessed incurring a cache miss, it will be at least as expensive as a
divide operation, and additional accesses to the same location are
roughly free." -- The Software Optimization Cookbook, Intel Press





More information about the Python-Dev mailing list