PEP 260: simplify xrange()

[Guido van Rossum]

Grant Griffin <not.this at seebelow.org> writes:

> I like it, but I can think of two questions that might be answered
> within the PEP.

I'm not sure these need to be answered in the PEP, but the answers are
trivial.

> 1) What is the effect on speed?  Presumably speed will increase (or at
> least stay the same), but, heck--who knows?

The xrange object becomes one C long smaller, and creating an xrange()
object will be a tad faster -- the creation routine is simplified.
Indexing may or may not become faster; the common path through that
code is the same, but there's a jump over less code now.  (Hm, I could
speed it up some more by a small code rearrangement.)

> 2) How do the functions from xrange relate--semantically speaking--to
> the functions of "xreadlines()"?  It seems to me that the two should
> have a similar "user interface" because they work about the same way,
> and solve similar problems.

xreadlines() already follows the new xrange() philosophy.  Even
better, xreadlines() allows you to loop over it only once, and you
have to use the natural indexing sequence.  This makes it easier to
turn xreadlines() into a pure iterator -- this can't be done with
xrange(), because of the following common idiom:

  r = xrange(1000000)
  for i in r: f1()
  for i in r: f2()

--Guido van Rossum (home page: http://www.python.org/~guido/)