Pourquoi n'y a-t-il pas de fonction xrange en Python3?

Récemment, j'ai commencé à utiliser Python3 et son manque de xrange fait mal.

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

Les résultats sont respectivement:

1) 1,53888392448 2) 3,215819835662842

Pourquoi donc? Je veux dire, pourquoi xrange a été supprimé? C'est un excellent outil pour apprendre. Pour les débutants, tout comme moi, comme nous l'étions tous à un moment donné. Pourquoi l'enlever? Quelqu'un peut-il m'indiquer le PEP approprié, je ne le trouve pas.

À votre santé.

Certaines mesures de performances, en utilisant timeitau lieu d'essayer de le faire manuellement avec time.

Tout d'abord, Apple 2.7.2 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

Maintenant, python.org 3.3.0 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

Apparemment, 3.x rangeest vraiment un peu plus lent que 2.x xrange. Et la xrangefonction de l'OP n'a rien à voir avec cela. (Pas étonnant, car un appel unique à l' __iter__emplacement n'est probablement pas visible parmi 10000000 appels à tout ce qui se passe dans la boucle, mais quelqu'un l'a évoqué comme une possibilité.)

Mais c'est seulement 30% plus lent. Comment l'OP est-il devenu 2x plus lent? Eh bien, si je répète les mêmes tests avec Python 32 bits, j'obtiens 1,58 contre 3,12. Donc, je suppose que c'est encore un autre de ces cas où 3.x a été optimisé pour des performances 64 bits d'une manière qui nuit à 32 bits.

Mais est-ce que c'est vraiment important? Vérifiez cela, avec 3.3.0 64 bits à nouveau:

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

Ainsi, la construction de listprend plus de deux fois plus de temps que l'itération entière.

Et quant à «consomme beaucoup plus de ressources que Python 2.6+», d'après mes tests, il semble qu'un 3.x rangesoit exactement de la même taille qu'un 2.x xrange- et, même s'il était 10 fois plus grand, la construction de la liste inutile est toujours environ 10000000x plus un problème que tout ce que l'itération de plage pourrait faire.

Et qu'en est-il d'une forboucle explicite au lieu de la boucle C à l'intérieur 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

Donc, presque autant de temps perdu dans la fordéclaration que dans le travail réel d'itération de la range.

Si vous craignez d'optimiser l'itération d'un objet de plage, vous cherchez probablement au mauvais endroit.

Pendant ce temps, vous continuez à demander pourquoi a xrangeété supprimé, peu importe le nombre de fois que les gens vous disent la même chose, mais je vais le répéter: il n'a pas été supprimé: il a été renommé rangeet le 2.x rangeest ce qui a été supprimé.

Voici une preuve que l' rangeobjet 3.3 est un descendant direct de l' xrangeobjet 2.x (et non de la rangefonction 2.x ): la source de 3.3range et 2.7xrange . Vous pouvez même voir l' historique des modifications (lié, je crois, à la modification qui a remplacé la dernière instance de la chaîne "xrange" n'importe où dans le fichier).

Alors, pourquoi est-ce plus lent?

Eh bien, pour commencer, ils ont ajouté beaucoup de nouvelles fonctionnalités. D'autre part, ils ont fait toutes sortes de changements partout (en particulier à l'intérieur de l'itération) qui ont des effets secondaires mineurs. Et il y avait eu beaucoup de travail pour optimiser considérablement divers cas importants, même si cela pessimise parfois légèrement les cas moins importants. Ajoutez tout cela, et je ne suis pas surpris que l'itération rangeaussi rapide que possible soit maintenant un peu plus lente. C'est l'un de ces cas moins importants sur lesquels personne ne se soucierait jamais suffisamment de se concentrer. Personne n'est susceptible d'avoir un cas d'utilisation réel où cette différence de performances est le point chaud dans leur code.

La gamme de python3 est le xrange de python2. Il n'est pas nécessaire d'envelopper un iter autour de lui. Pour obtenir une liste réelle en Python3, vous devez utiliserlist(range(...))

Si vous voulez quelque chose qui fonctionne avec Python2 et Python3, essayez ceci

try:
    xrange
except NameError:
    xrange = range

Le rangetype de Python 3 fonctionne exactement comme Python 2 xrange. Je ne sais pas pourquoi vous voyez un ralentissement, car l'itérateur renvoyé par votre xrangefonction est exactement ce que vous obtiendriez si vous répétiez rangedirectement.

Je ne parviens pas à reproduire le ralentissement sur mon système. Voici comment j'ai testé:

Python 2, avec 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, avec rangeest un tout petit peu plus rapide:

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

J'ai récemment appris que le rangetype de Python 3 possède d'autres fonctionnalités intéressantes, telles que la prise en charge du découpage: range(10,100,2)[5:25:5]c'est range(20, 60, 10)!

Une façon de corriger votre code python2 est:

import sys

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

xrange de Python 2 est un générateur et implémente un itérateur tandis que la plage n'est qu'une fonction. En Python3, je ne sais pas pourquoi a été abandonné le xrange.

comp: ~ $ python Python 2.7.6 (par défaut, 22 juin 2015, 17:58:13) [GCC 4.8.2] sur 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

Avec 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 (par défaut, 14 octobre 2015, 20:28:29) [GCC 4.8.4] sous 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

Avec timeit number = 1,2,3,4 param fonctionne rapidement et de manière linéaire:

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

Il semble donc que si nous mesurons 1 cycle de boucle en cours comme timeit.timeit ("[x pour x dans la plage (1000000) si x% 4]", nombre = 1) (comme nous l'utilisons réellement dans le code réel) python3 fonctionne assez rapidement, mais dans les boucles répétées, python 2 xrange () gagne en vitesse contre range () de python 3.