Should you always favor xrange() over range()?

Why or why not?

From stackoverflow mbac32768

• xrange() is more efficient because instead of generating a list of objects, it just generates one object at a time. Instead of 100 integers, and all of their overhead, and the list to put them in, you just have one integer at a time. Faster generation, better memory use, more efficient code.

  Unless I specifically need a list for something, I always favor xrange()

  From Dan Udey

• You should favour range() over xrange() only when you need an actual list. For instance, when you want to modify the list returned by range(), or when you wish to slice it. For iteration or even just normal indexing, xrange() will work fine (and usually much more efficiently). There is a point where range() is a bit faster than xrange() for very small lists, but depending on your hardware and various other details, the break-even can be at a result of length 1 or 2; not something to worry about. Prefer xrange().

  From Thomas Wouters

• Go with range for these reasons:

  1) xrange will be going away in newer Python versions. This gives you easy future compatibility.

  2) range will take on the efficiencies associated with xrange.

  Thomas Wouters : Don't do this. xrange() will go away, but so will a lot of other things. The tool you will be using to translate your Python 2.x code into Python 3.x code will automatically translate xrange() to range(), but range() will be translated to the less efficient list(range()).

  Brian : Thomas: Its actually a bit smarter than that. It'll translate range() in situations where it clearly doesn't need a real list (eg in a for loop, or comprehension) to just plain range(). Only cases where it gets assigned to a variable, or used directly must be wrapped with list()
  From torial

• For performance, especially when you're iterating over a large range, xrange() is usually better. However, there are still a few cases why you might prefer range():

  • In python 3, range() will become an iterator anyway and will be the preferred spelling (I'm not sure if xrange will still exist for compatability - probably not though). Using range() may make your code more portable going forward.

  • range() can actually be faster in some cases - eg. if iterating over the same sequence multiple times. xrange has to reconstruct the integer object every time, but range will have real integer objects. (It will always perform worse in terms of memory however)

  • xrange isn't usable in all cases where a real list is needed. For instance, it doesn't support slices, or any list methods.

  [Edit] There are a couple of posts mentioning how range() will be upgraded by the 2to3 tool. For the record, here's the output of running the tool on some sample usages of range() and xrange()

  RefactoringTool: Skipping implicit fixer: buffer
  RefactoringTool: Skipping implicit fixer: idioms
  RefactoringTool: Skipping implicit fixer: ws_comma
  --- range_test.py (original)
  +++ range_test.py (refactored)
  @@ -1,7 +1,7 @@
  
   for x in range(20):
  -    a=range(20)
  +    a=list(range(20))
       b=list(range(20))
       c=[x for x in range(20)]
       d=(x for x in range(20))
  -    e=xrange(20)
  +    e=range(20)
  

  As you can see, when used in a for loop or comprehension, or where already wrapped with list(), range is left unchanged.

  J.F. Sebastian : +1: for the diff which shows that lisr(range()) is left unchanged.
  From Brian

• range() returns a list, xrange() returns an xrange object.

  xrange() is a bit faster, and a bit more memory efficient. But the gain is not very large.

  The extra memory used by a list is of course not just wasted, lists have more functionality (slice, repeat, insert, ...). Exact differences can be found in the documentation. There is no bonehard rule, use what is needed.

  Python 3.0 is still in development, but IIRC range() will very similar to xrange() of 2.X and list(range()) can be used to generate lists.

  From jschultz

• Okay, everyone here as a different opinion as to the tradeoffs and advantages of xrange versus range. They're mostly correct, xrange is an iterator, and range fleshes out and creates an actual list. For the majority of cases, you won't really notice a difference between the two. (You can use map with range but not with xrange, but it uses up more memory.)

  What I think you rally want to hear, however, is that the preferred choice is xrange. Since range in Python 3 is an iterator, the code conversion tool 2to3 will correctly convert all uses of xrange to range, and will throw out an error or warning for uses of range. If you want to be sure to easily convert your code in the future, you'll use xrange only, and list(xrange) when you're sure that you want a list. I learned this during the CPython sprint at PyCon this year (2008) in Chicago.

  Brian : Thats not true. Code like "for x in range(20)" will be left as range, and code like "x=range(20)" will be converted to "x=list(range(20))" - no errors. Further, if you want to write code that will run under both 2.6 and 3.0, range() is your only option without adding compatability functions.
  From Douglas Mayle

• No, they both have their uses:

  Use xrange() when iterating, as it saves memory. Say:

  for x in xrange(1, one_zillion):
  

  rather than:

  for x in range(1, one_zillion):
  

  On the other hand, use range() if you actually want a list of numbers.

  multiples_of_seven = range(7,100,7)
  print "Multiples of seven < 100: ", multiples_of_seven
  

  From Dan