Чому в Python3 немає функції xrange?

Нещодавно я почав використовувати Python3, і це не вистачає xrange боляче.

Простий приклад:

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

Результати, відповідно:

1) 1.53888392448 2) 3.215819835662842

Чому так? Я маю на увазі, чому xrange видалено? Це такий чудовий інструмент для навчання. Для початківців, як і я, як і всі ми були в якийсь момент. Навіщо його видаляти? Хтось може вказати мені на належний PEP, я не можу його знайти.

Ура.

Деякі вимірювання продуктивності, використовуючи timeit замість того, щоб намагатися робити це вручну time.

По-перше, 64-розрядний Apple 2.7.2:

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

Тепер, python.org 3.3.0 64-розрядний:

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

Мабуть, 3.x rangeнасправді трохи повільніше, ніж 2.xxrange . І xrangeфункція ОП не має нічого спільного. (Не дивно, що одноразовий дзвінок у __iter__слот, ймовірно, не буде видно серед 10000000 дзвінків у будь-якому випадку, що відбувається в циклі, але хтось вивів це як можливість.)

Але це лише на 30% повільніше. Як ОП вийшла в 2 рази настільки повільно? Ну якщо я повторюю ті ж тести з 32-розрядним Python, я отримую 1,58 проти 3,12. Тож я здогадуюсь, що це ще один із тих випадків, коли 3.x був оптимізований для 64-бітної продуктивності способами, які шкодять 32-бітовій.

Але чи насправді це має значення? Перевірте це, з 3.3.0 64-розрядними знову:

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

Отже, будуючи list займає більше ніж удвічі довше, ніж уся ітерація.

А що стосується "споживає набагато більше ресурсів, ніж Python 2.6+", то з моїх тестів, схоже, що 3.x rangeточно такого ж розміру, як і 2.xxrange і навіть якщо він був 10x більшим, будуючи непотрібний список все ще приблизно 10000000x більше проблеми, ніж все, що може зробити ітерація діапазону.

А як щодо явного forциклу замість циклу C всередині 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

Отже, майже стільки ж часу витрачається на forвиписку, як і в реальній роботі ітераціїrange .

Якщо ви переживаєте за оптимізацію ітерації об’єкта діапазону, ви, ймовірно, шукаєте в неправильному місці.

Тим часом ви постійно запитуєте, чому xrangeйого видалили, незалежно від того, скільки разів люди вам скажуть одне і те ж, але я повторю це ще раз: його не видаляли: його перейменовували range, а 2.x range- це те, що було видалено.

Ось деякі докази того, що rangeоб’єкт 3.3 є прямим нащадком xrangeоб'єкта 2.x (а не rangeфункції 2.x ): джерела до 3.3range та 2.7xrange . Ви навіть можете бачити історію змін (пов'язана, я вважаю, з зміною, яка замінила останній екземпляр рядка "xrange" в будь-якому місці файлу).

Отже, чому це повільніше?

Ну, для одного вони додали багато нових функцій. З іншого боку, вони вносили всілякі зміни всюди (особливо всередині ітерації), які мають незначні побічні ефекти. І було дуже багато роботи, щоб різко оптимізувати різні важливі справи, навіть якщо це іноді трохи песимізує менш важливі справи. Додайте це все, і я не здивований, що повторення rangeякнайшвидше зараз трохи повільніше. Це один із тих менш важливих випадків, на який ніхто ніколи не піклується, щоб зосередитися. Ніхто, ймовірно, ніколи не матиме випадків використання в реальному житті, коли ця різниця в продуктивності є точкою доступу у їхньому коді.

Діапазон Python3 - це помаранчевий колір Python2. Немає потреби обертати навколо неї ітер. Щоб отримати фактичний список у Python3, вам потрібно скористатисяlist(range(...))

Якщо ви хочете щось, що працює з Python2 та Python3, спробуйте це

try:
    xrange
except NameError:
    xrange = range

rangeТип Python 3 працює так само, як і Python 2 xrange. Я не впевнений, чому ви спостерігаєте уповільнення, оскільки ітератор, який повернувся за вашою xrangeфункцією, саме те, що ви отримаєте, якщо перейдете rangeбезпосередньо.

Я не в змозі відтворити уповільнення моєї системи. Ось як я тестував:

Python 2, із 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, with range- це трохи швидше:

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

Нещодавно я дізнався, що rangeтип Python 3 має деякі інші акуратні особливості, такі як підтримка нарізки: range(10,100,2)[5:25:5]є range(20, 60, 10)!

Один із способів виправити ваш код python2:

import sys

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

xrange від Python 2 є генератором і реалізує ітератор, тоді як діапазон - лише функція. У Python3 я не знаю, чому скинув xrange.

комп .: ~ $ python Python 2.7.6 (за замовчуванням, 22 червня 2015, 17:58:13) [GCC 4.8.2] у 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

З номером timeit = 1 парам:

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

комп .: ~ $ python3 Python 3.4.3 (за замовчуванням, 14 жовтня 2015, 20:28:29) [GCC 4.8.4] у 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

З числом timeit = 1,2,3,4 парам працює швидко і лінійно:

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

Тож здається, що якщо ми виміряємо 1 цикл запущеного циклу, як timeit.timeit ("[x для x у діапазоні (1000000), якщо x% 4]", число = 1) (як ми насправді використовуємо в реальному коді) python3 працює досить швидко, але в повторних циклах python 2 xrange () виграє у швидкості проти діапазону () від python 3.