¿Por qué no hay función xrange en Python3?

Recientemente comencé a usar Python3 y me duele la falta de xrange.

Ejemplo simple:

1) Python2:

from time import time as t
def count():
  st = t()
  [x for x in xrange(10000000) if x%4 == 0]
  et = t()
  print et-st
count()

2) Python3:

from time import time as t

def xrange(x):

    return iter(range(x))

def count():
    st = t()
    [x for x in xrange(10000000) if x%4 == 0]
    et = t()
    print (et-st)
count()

Los resultados son, respectivamente:

1) 1.53888392448 2) 3.215819835662842

¿Porqué es eso? Quiero decir, ¿por qué se ha eliminado xrange? Es una gran herramienta para aprender. Para los principiantes, como yo, como todos estábamos en algún momento. ¿Por qué eliminarlo? ¿Alguien puede señalarme la PEP adecuada? No puedo encontrarla.

Salud.

Algunas medidas de rendimiento, utilizando en timeitlugar de intentar hacerlo manualmente time.

Primero, Apple 2.7.2 de 64 bits:

In [37]: %timeit collections.deque((x for x in xrange(10000000) if x%4 == 0), maxlen=0)
1 loops, best of 3: 1.05 s per loop

Ahora, python.org 3.3.0 de 64 bits:

In [83]: %timeit collections.deque((x for x in range(10000000) if x%4 == 0), maxlen=0)
1 loops, best of 3: 1.32 s per loop

In [84]: %timeit collections.deque((x for x in xrange(10000000) if x%4 == 0), maxlen=0)
1 loops, best of 3: 1.31 s per loop

In [85]: %timeit collections.deque((x for x in iter(range(10000000)) if x%4 == 0), maxlen=0) 
1 loops, best of 3: 1.33 s per loop

Al parecer, 3.x rangerealidad es un poco más lento que 2.x xrange. Y la xrangefunción del OP no tiene nada que ver con eso. (No es sorprendente, ya que __iter__no es probable que una llamada única a la ranura sea visible entre 10000000 llamadas a lo que ocurra en el bucle, pero alguien lo mencionó como una posibilidad).

Pero es solo un 30% más lento. ¿Cómo llegó el OP 2 veces más lento? Bueno, si repito las mismas pruebas con Python de 32 bits, obtengo 1.58 vs. 3.12. Entonces, supongo que este es otro de esos casos en los que 3.x ha sido optimizado para un rendimiento de 64 bits en formas que perjudican a 32 bits.

pero, realmente importa? Mira esto, con 3.3.0 64 bits nuevamente:

In [86]: %timeit [x for x in range(10000000) if x%4 == 0]
1 loops, best of 3: 3.65 s per loop

Por lo tanto, construir el listtoma más del doble de tiempo que la iteración completa.

Y en cuanto a "consume muchos más recursos que Python 2.6+", según mis pruebas, parece que un 3.x rangetiene exactamente el mismo tamaño que un 2.x xrange, e, incluso si fuera 10 veces más grande, construir la lista innecesaria sigue siendo aproximadamente 10000000x un problema mayor que cualquier cosa que la iteración de rango pueda hacer.

¿Y qué hay de un forbucle explícito en lugar del bucle C dentro deque?

In [87]: def consume(x):
   ....:     for i in x:
   ....:         pass
In [88]: %timeit consume(x for x in range(10000000) if x%4 == 0)
1 loops, best of 3: 1.85 s per loop

Entonces, casi tanto tiempo perdido en la fordeclaración como en el trabajo real de iterar el range.

Si le preocupa optimizar la iteración de un objeto de rango, probablemente esté buscando en el lugar equivocado.

Mientras tanto, sigues preguntando por qué xrange se eliminó, no importa cuántas veces la gente le diga lo mismo, pero lo repetiré nuevamente: no se eliminó: se cambió el nombre a range, y el 2.x rangees lo que se eliminó.

Aquí hay alguna prueba de que el rangeobjeto 3.3 es un descendiente directo del xrangeobjeto 2.x (y no de la rangefunción 2.x ): la fuente de 3.3range y 2.7xrange . Incluso puede ver el historial de cambios (vinculado, creo, al cambio que reemplazó la última instancia de la cadena "xrange" en cualquier parte del archivo).

Entonces, ¿por qué es más lento?

Bueno, por un lado, han agregado muchas características nuevas. Por otro lado, han realizado todo tipo de cambios en todo el lugar (especialmente dentro de la iteración) que tienen efectos secundarios menores. Y ha habido mucho trabajo para optimizar dramáticamente varios casos importantes, incluso si a veces pesimiza ligeramente los casos menos importantes. Agregue todo esto, y no me sorprende que iterar lo rangemás rápido posible ahora sea un poco más lento. Es uno de esos casos menos importantes en los que nadie se preocuparía lo suficiente. Es probable que nadie tenga un caso de uso real en el que esta diferencia de rendimiento sea el punto clave en su código.

El rango de Python3 es el xrange de Python2. No hay necesidad de rodearlo. Para obtener una lista real en Python3, debe usarlist(range(...))

Si quieres algo que funcione con Python2 y Python3, prueba esto

try:
    xrange
except NameError:
    xrange = range

El rangetipo de Python 3 funciona igual que el de Python 2 xrange. No estoy seguro de por qué está viendo una desaceleración, ya que el iterador devuelto por su xrangefunción es exactamente lo que obtendría si iterararange directamente.

No puedo reproducir la desaceleración en mi sistema. Así es como lo probé:

Python 2, con xrange:

Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import timeit
>>> timeit.timeit("[x for x in xrange(1000000) if x%4]",number=100)
18.631936646865853

Python 3, con rangees un poco más rápido:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import timeit
>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=100)
17.31399508687869

Hace poco aprendí que el rangetipo de Python 3 tiene algunas otras características interesantes, como el soporte para cortar: ¡ range(10,100,2)[5:25:5]es range(20, 60, 10)!

Una forma de arreglar su código python2 es:

import sys

if sys.version_info >= (3, 0):
    def xrange(*args, **kwargs):
        return iter(range(*args, **kwargs))

xrange de Python 2 es un generador e implementa un iterador, mientras que el rango es solo una función. En Python3 no sé por qué se dejó caer la xrange.

comp: ~ $ python Python 2.7.6 (predeterminado, 22 de junio de 2015, 17:58:13) [GCC 4.8.2] en linux2

>>> import timeit
>>> timeit.timeit("[x for x in xrange(1000000) if x%4]",number=100)

5.656799077987671

>>> timeit.timeit("[x for x in xrange(1000000) if x%4]",number=100)

5.579368829727173

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=100)

21.54827117919922

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=100)

22.014557123184204

Con timeit number = 1 param:

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=1)

0.2245171070098877

>>> timeit.timeit("[x for x in xrange(1000000) if x%4]",number=1)

0.10750913619995117

comp: ~ $ python3 Python 3.4.3 (predeterminado, 14 de octubre de 2015, 20:28:29) [GCC 4.8.4] en Linux

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=100)

9.113872020003328

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=100)

9.07014398300089

Con timeit number = 1,2,3,4 param funciona de forma rápida y lineal:

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=1)

0.09329321900440846

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=2)

0.18501482300052885

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=3)

0.2703447980020428

>>> timeit.timeit("[x for x in range(1000000) if x%4]",number=4)

0.36209142999723554

Entonces parece que si medimos 1 ciclo de ciclo de ejecución como timeit.timeit ("[x para x en el rango (1000000) si x% 4]", número = 1) (como realmente usamos en código real) python3 funciona lo suficientemente rápido, pero en bucles repetidos, python 2 xrange () gana en velocidad contra range () desde python 3.