[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4