difference between range in py3 and xrange in py2

[Skaperen]

Output:
lt1/forums /home/forums 1> py3
Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> range(9)[:]
range(0, 9)
>>> 
lt1/forums /home/forums 2> py2
Python 2.7.12 (default, Nov 20 2017, 18:23:56) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> xrange(9)[:]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sequence index must be integer, not 'slice'
>>> 
lt1/forums /home/forums 3>

[Larz60+]

from google search 'difference between xrange and range python'

They both provide a way to generate a list of integers for you to use, however you please. The only difference is that range returns a Python list object and xrange returns an xrange object. ... It means that xrange doesn't actually generate a static list at run-time like range does.

[Skaperen]

that quote is comparing xrange to range both in Python2. Python3 is being promoted as removing the original range that yields a real list and renaming xrange to range. but that is not entirely accurate. Python3 is still a fine improvement over Python2 and everyone making a choice for a new project should choose Python3 unless something forces them to go with Python2.

[wavic]

Here is explained pretty well:
http://treyhunner.com/2018/02/python-ran...-iterator/
http://treyhunner.com/2018/02/python-3-s...-s-xrange/

I found this few days ago but I didn't read it in full.

[nilamo]

xrange in python2 is just a generator. In python3, it's a special class that normally acts like a generator, but also supports slicing/indexing/min/max/len, using math to calculate what those values would be (instead of exhausting the range), so it's still very fast.

[Skaperen]

xrange in python2 is just a generator. In python3, it's a special class that normally acts like a generator, but also supports slicing/indexing/min/max/len, using math to calculate what those values would be (instead of exhausting the range), so it's still very fast.

but in a straight assignment to a variable, they can operate differently giving surprises because you are getting something different. that's not how Python3 was promoted.

[wavic]

I don't know how Python 3 is promoted but there is no programming language out there that has full compatibility between major versions.
Both xrange and python's 3 range are their own classes. Both have same functionality but their methods differs. I think this is advantage not inconvenience. This is evolving. It's not normal to keep all the old behaviour and methods. If it was the opposite a language package will be several gigabytes. And inventing new classes and functions name that are descriptive and not in conflict with the old ones will become something impossible.

[nilamo]

that's not how Python3 was promoted.

Sure it was. Python3 was always advertised as backwards incompatible, and that it was breaking things in the name of progress.

[Skaperen]

but what i read was that python3:range was supposed to be compatible with python2:xrange, justifying the removal of python2:range. but, IMHO, python2:range did not need any justification to be removed. whatever. python3:range is fully usable. i guess that must be what they meant by compatible.

[vishalhule]

In Python 3, they removed the original range()function and renamed xrange of python 2.x to range in python 3.x
basic functionality is the same between xrange and range.

Differences:
Two xrange objects will not be seen as equal unless they are actually the same exact object
Whereas a comparison between two range objects in Python 3 actually checks whether the start, stop, and step of each object is equal.