Por que não há função xrange no Python3?

Recentemente eu comecei a usar Python3 e é a falta de xrange dói.

Exemplo simples:

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()

Os resultados são, respectivamente:

1) 1.53888392448 2) 3.215819835662842

Por que é que? Quero dizer, por que xrange foi removido? É uma ótima ferramenta para aprender. Para os iniciantes, assim como eu, como todos nós estávamos em algum momento. Por que removê-lo? Alguém pode me indicar o PEP adequado, não consigo encontrá-lo.

Felicidades.

Algumas medições de desempenho, usando em timeitvez de tentar fazê-lo manualmente time.

Primeiro, o 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

Agora, 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

Aparentemente, 3.x rangerealmente é um pouco mais lento do que 2.x xrange. E a xrangefunção do OP não tem nada a ver com isso. (Não é surpresa, uma vez que uma chamada única para o __iter__slot provavelmente não será visível entre 10000000 chamadas para o que acontecer no loop, mas alguém a abordou como uma possibilidade.)

Mas é apenas 30% mais lento. Como o OP ficou 2x mais lento? Bem, se eu repetir os mesmos testes com o Python de 32 bits, recebo 1,58 vs. 3,12. Então, meu palpite é que esse é mais um daqueles casos em que o 3.x foi otimizado para desempenho de 64 bits de maneiras que prejudicam 32 bits.

Mas isso realmente importa? Verifique isso com o 3.3.0 de 64 bits novamente:

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

Portanto, a construção do listleva mais que o dobro do tempo da iteração inteira.

E quanto a "consome muito mais recursos que o Python 2.6+", nos meus testes, parece que um 3.x rangeé exatamente do mesmo tamanho que um 2.x xrange- e, mesmo que fosse 10 vezes maior, cria a lista desnecessária ainda é 10000000x mais problemático do que qualquer coisa que a iteração de alcance possa fazer.

E o que dizer de um forloop explícito em vez do loop 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

Portanto, quase tanto tempo perdido na fordeclaração quanto no trabalho real de iterar o range.

Se você está preocupado em otimizar a iteração de um objeto de intervalo, provavelmente está procurando o lugar errado.

Enquanto isso, você continua perguntando por que xrangefoi removido, não importa quantas vezes as pessoas lhe digam a mesma coisa, mas vou repetir novamente: Não foi removido: foi renomeado para rangee o 2.x rangefoi removido.

Aqui estão algumas provas de que o rangeobjeto 3.3 é um descendente direto do xrangeobjeto 2.x (e não da rangefunção 2.x ): a origem para 3.3range e 2.7xrange . Você pode até ver o histórico de alterações (vinculado a, acredito, a alteração que substituiu a última instância da string "xrange" em qualquer lugar do arquivo).

Então, por que é mais lento?

Bem, por um lado, eles adicionaram muitos recursos novos. Por outro lado, eles fizeram todos os tipos de alterações em todo o lugar (especialmente na iteração interna) que têm efeitos colaterais menores. E havia muito trabalho para otimizar dramaticamente vários casos importantes, mesmo que às vezes pessimizasse levemente casos menos importantes. Adicione tudo isso, e não estou surpreso que iterar o rangemais rápido possível seja agora um pouco mais lento. É um daqueles casos menos importantes que ninguém jamais se importaria o suficiente para focar. É provável que ninguém tenha um caso de uso da vida real em que essa diferença de desempenho seja o ponto de acesso em seu código.

O intervalo do Python3 é o xrange do Python2. Não há necessidade de envolver um iter. Para obter uma lista real no Python3, você precisa usarlist(range(...))

Se você deseja algo que funcione com Python2 e Python3, tente este

try:
    xrange
except NameError:
    xrange = range

O rangetipo do Python 3 funciona como o Python 2 xrange. Não sei por que você está vendo uma desaceleração, pois o iterador retornado por sua xrangefunção é exatamente o que você obteria se iterasse rangediretamente.

Não consigo reproduzir a desaceleração no meu sistema. Aqui está como eu testei:

Python 2, com 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, com rangeé um pouco mais 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

Eu aprendi recentemente que o rangetipo do Python 3 tem outros recursos interessantes, como o suporte para fatiar: range(10,100,2)[5:25:5]is range(20, 60, 10)!

Uma maneira de corrigir seu código python2 é:

import sys

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

O xrange do Python 2 é um gerador e implementa o iterador, enquanto o range é apenas uma função. No Python3, não sei por que foi retirado do xrange.

comp: ~ $ python Python 2.7.6 (padrão, 22 de junho de 2015, 17:58:13) [GCC 4.8.2] no 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

Com 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 (padrão, 14 de outubro de 2015, 20:28:29) [GCC 4.8.4] no 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

Com timeit number = 1,2,3,4, o param funciona de maneira rápida e linear:

>>> 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

Parece que, se medirmos 1 ciclo de loop em execução, como timeit.timeit ("[x para x no intervalo (1000000) se x% 4]", número = 1) (como realmente usamos no código real) python3 funciona rápido o suficiente, mas em loops repetidos o python 2 xrange () vence em velocidade contra o range () do python 3.