Python 64-битный дает трассировку StopIteration при использовании next () - но 32-битный нет - PullRequest
Новая
       45

Python 64-битный дает трассировку StopIteration при использовании next () - но 32-битный нет

0 голосов
/ 08 июля 2019

Примечание заранее: в Интернете я нашел (очень!) Тесно связанные вопросы и информацию, но ничего, что вполне решает проблему, с которой я сталкиваюсь.

Эта проблема относится к этой статье, в частности, опция list-all-files, которая включает использование функции next() на os.walk().Чтобы сузить его, я создал этот трехстрочный скрипт: 

import os
allFiles = next(os.walk(os.path.dirname(__file__)))[2]
print(allFiles)

Когда я запускаю этот скрипт на 32-битной версии Python 3.7.2 (для Windows), он завершается нормально и распечатывает все файлыв папке скрипта.

Но когда я запускаю его на 64-битной версии 3.7.2 (также для Windows), он заканчивается трассировкой, указывающей исключение StopIteration: 

Traceback (most recent call last):
  File "test.py", line 3, in <module>
    allFiles = next(os.walk(os.path.dirname(__file__)))[2]
StopIteration

Вопрос не в том, почему я получаю это исключение?потому что ответ очевиден, я получаю его, потому что в next() закончились элементы.

Скорее вопрос: "Почему этот код прекрасно работает на 32-битной версии Python, ноне в 64-битной версии? " И, кроме того, " Какая версия демонстрирует правильное / намеченное поведение? "

Единственный совет, который я нашел, было это утверждение в документации по Python :

Изменено в версии 3.7: Включить PEP 479 для всего кода по умолчанию: ошибка StopItra, возникающая в генераторе, преобразуется в RuntimeError.

Похоже, что запись для PEP 479 говорит о том, что поведение, которое я вижу в 64-битной версии, было преднамеренным изменением в 3.7, чтобы уменьшить неожиданности и предотвратить неясные и скрытые ошибки.Если я правильно читаю, то 64-битная версия верна, а 32-битная неверна.Хотя у меня возникли проблемы с пониманием этого, тем более что в статье , которая в первую очередь привела меня к этой проблеме, представляет использование next(os.walk(...)) в качестве простой опции, которая всегда будет работать ... но сейчас, это не так.

Эта запись на github , похоже, относится к этой проблеме - и если я прав в этом, это также означает, что я не единственный, кто былудивлен этим изменением, чтобы предотвратить неожиданности.

...