Nitpicking, but this statement doesn't work with large numbers (which xrange() is supposed to handle correctly):<p><pre><code> self._len = int(ceil(float(stop - start) / step))
</code></pre>
Python supports arbitrary-length integers; you can't just cast those to (fixed-length) floating point numbers without losing precision. It's better to use integer division here, for example:<p><pre><code> self._len = (stop - start)//step + bool((stop - start)%step)
</code></pre>
(A variant like (stop - start + step - 1)//step works only for positive numbers; I guess it could work if you put it in the earlier if-clause and put a corresponding assignment with +1 at the end in the other branch.)
Nice.<p>As a side-note, here's a related article on implementing a Python generator "for real" using the C API: <a href="http://eli.thegreenplace.net/2012/04/05/implementing-a-generatoryield-in-a-python-c-extension/" rel="nofollow">http://eli.thegreenplace.net/2012/04/05/implementing-a-gener...</a>
I had a _very_ similar question during my Google interview. In the course of the day I was tasked with implementing a generator (although answering with `(x for x in foo)` got a smile I did have to build a class) and later in the day was asked how a sequence manager can maintain constant time.<p>This is an excellent post and every Python hacker should read it. Kudos to the author.
This is cool. I know this isn't how they actually do it, but seeing it in a language I can understand (Python) and not in C is really pleasing.<p>You can do tons of examples, but until you figure out how the machine works inside, you'll be completely lost (you could get it with examples, but you won't necessarily know WHY you got it, so you'll be useless in helping other people learn).
Not worth a pull request, but personally I'd replace:<p><pre><code> if len(args) == 1:
start, stop, step = 0, args[0], 1
elif len(args) == 2:
start, stop, step = args[0], args[1], 1
elif len(args) == 3:
start, stop, step = args
else:
raise TypeError('xrange() requires 1-3 int arguments')
</code></pre>
with:<p><pre><code> map = [
lambda args: (0, args[0], 1),
lambda args: (args[0], args[1], 1),
lambda args: args,
]
try:
start, stop, step = map[len(args)](args)
except IndexError:
raise TypeError('xrange() requires 1-3 int arguments')
</code></pre>
It's more DRY, and it conveys the intent better.<p>I would <i>not</i> do such a change to the <i>if step</i> block since its pattern feels noticeably different: "open" checks fit well in a <i>if/else</i>, whereas bunch-of-equalities fit a dispatch map better (plus you can actually modify the map at runtime).
Answers to <a href="http://stackoverflow.com/questions/1482480/xrange2100-overflowerror-long-int-too-large-to-convert-to-int" rel="nofollow">http://stackoverflow.com/questions/1482480/xrange2100-overfl...</a>
contain several implementations of xrange() in pure Python
I cried a little bit on the inside when he said that that the iterator should not be implemented using generators, etc. Writing iterators by hand forces one to turn the iteration code inside out and it can be a painful experience if the logic is anything nontrivial.
I feel that this kind of combination of lazy evaluation for sequences, together with eager evaluation for imperative code hits a particular sweet spot. Python and Clojure have very nice lazy sequences.