Всем привет! Меня зовут Ефимов Михаил, я профессиональный разработчик с 2010 года и начинающий contributor в CPython.
Итак, название статьи говорит, что генераторные выражения сломаны. О чем вообще речь? Посмотрим на такой код, не содержащий никаких import:
g = (x for x in range(10)) g.gi_frame.f_locals['.0'] = range(20) list(g)Устанавливаем с официального сайта новенький Python 3.13.0. Запускаем интерпретатор в режиме консоли, копируем в консоль эти строки кода, ожидаем увидеть содержимое списка…
А содержимого никакого нет, да и консоль закрылась — интерпретатор завершил работу. В зависимости от того, на какой операционной системе был запущен код, будет сформирован Segmentation Fault или его вариации. Например, Windows использует обозначение STATUS_ACCESS_VIOLATION, но суть та же.
Для подобных исследований нам пригодится faulthandler из стандартной библиотеки:
>>> import faulthandler >>> faulthandler.enable() >>> g = (x for x in range(10)) >>> g.gi_frame.f_locals['.0'] = range(20) >>> list(g) Windows fatal exception: access violation Current thread 0x000018bc (most recent call first): File "<python-input-13>", line 1 in <genexpr> File "<python-input-15>", line 1 in <module> …Что ж, всё честно, crash на месте, а теперь давайте разбираться, что вообще произошло. Благо, строчек у нас всего три, так что мы можем подробно описать все объекты, вызовы методов и функций.
Встроенный объект range и генераторные выражения
Первая строка:
g = (x for x in range(10))Тут фигурирует некий вызов range(10), с него и начнем. В Python3 range — это встроенный объект, реализация которого написана на Си. Он ценен тем, что является Iterable, то есть из него можно получить итератор при помощи встроенной функции iter. Так как это built-in объект, то и реализация метода __iter__ у него специальная, возвращающая объект класса range_iterator.
С range разобрались, теперь к генераторным выражениям. Для начала, посмотрим на абстрактное синтаксическое дерево:
>>> import ast >>> print(ast.dump(ast.parse('(x for x in range(10))'), indent=2)) Module( body=[ Expr( value=GeneratorExp( elt=Name(id='x', ctx=Load()), generators=[ comprehension( target=Name(id='x', ctx=Store()), iter=Call( func=Name(id='range', ctx=Load()), args=[ Constant(value=10)]), is_async=0)]))])И на генерируемый байт-код:
>>> import dis >>> dis.dis('(x for x in range(10))') 0 RESUME 0 1 LOAD_CONST 0 (<code object <genexpr> ...>) MAKE_FUNCTION LOAD_NAME 0 (range) PUSH_NULL LOAD_CONST 1 (10) CALL 1 GET_ITER CALL 0 RETURN_VALUE Disassembly of <code object <genexpr> ...>)>: 1 RETURN_GENERATOR POP_TOP L1: RESUME 0 LOAD_FAST 0 (.0) L2: FOR_ITER 6 (to L3) STORE_FAST_LOAD_FAST 17 (x, x) YIELD_VALUE 0 RESUME 5 POP_TOP JUMP_BACKWARD 8 (to L2) L3: END_FOR POP_TOP RETURN_CONST 0 (None) -- L4: CALL_INTRINSIC_1 3 (INTRINSIC_STOPITERATION_ERROR) RERAISE 1 ExceptionTable: L1 to L4 -> L4 [0] lastiВидно, что байт-код состоит из двух частей. Отдельно описан вспомогательный code object <genexpr>, который реализует логику yield, выдающую значения «наружу». Посмотрите на инструкцию LOAD_FAST, она помещает на стек значение из переменной со странным именем '.0'!
Кроме того, в байт-коде присутствует “окружающий код”, который вычисляет значение iter(range(10)) и передает его в качестве единственного аргумента в сформированный code object. Вычисление этого выражения нетрудно проследить непосредственно, обратите внимание на инструкции LOAD_NAME, LOAD_CONST и CALL для вычисления range(10), к которому после применяется GET_ITER. И результат вычисления используется последующим CALL, относящемуся к code object <genexpr>. Определение built-in класса генератора можно посмотреть тут.
Итак, вернемся к выражению в первой строке:
g = (x for x in range(10))Переменной g присваивается значение генераторного выражения, записанного в правой части. В данном случае генератор получился максимально простой: каждому x из range(10) сопоставлено то же самое значение x.
Как известно, list(range(10)) всегда будет выдавать список от 0 до 9, а list(g) для нашего g — тот же список, но только один раз. Потому что после первого прохода g «закончится», и для получения тех же значений еще раз genexpr придется пересоздать. Кстати, именно list(g) и вызывается в третьей строке нашего теста. Но к этому моменту уже явно «что-то пошло не так», раз интерпретатор завершает работу.
Фреймы и f_locals
Что же случилось во второй строке:
g.gi_frame.f_locals['.0'] = range(20)Здесь присутствуют генератор g, некие gi_frame и f_locals и уже знакомый нам объект range. Рассмотрим их по порядку. Объект gi_frame — это специальный внутренний объект интерпретатора, называемый stack frame, который связан с нашим генератором. Причем фактически использован на стеке он будет только в момент итерирования генератора. Необходимость в отдельном stack frame обусловлена тем, что выполнение кода генератора прерывается каждый раз, когда в генераторной функции вызывается yield. Узнать, где именно прервалось выполнение, можно с помощью переменной g.gi_frame.f_lasti.
Перейдем к f_locals. Это Python-словарь, который описывает локальные переменные внутри определенного фрейма, ранее он содержал копии значений каждой переменной. Но посмотрим в актуальный PEP 667. Оказывается, начиная с Python 3.13, объект f_locals — это некий «view of namespace». Иными словами, f_locals выглядит как словарь, описывающий локальные переменные. Однако при изменении этого «как бы словаря» будет меняться не только значение внутри f_locals, но и реальное значение переменной внутри фрейма. Больше про f_locals можно почитать на Хабре тут.
Так что же происходит во второй строке? Фактически, мы меняем значение некой локальной переменной внутри генераторного фрейма с уже знакомым нам странным именем '.0'. А разве бывают переменные с таким названием, спросите вы? Бывают, но в очень специфических случаях, и это как раз он.
Рассмотрим чуть внимательнее code object, связанный с g:
>>> g = (x for x in range(10)) >>> g.gi_frame.f_code is g.gi_code True >>> import dis >>> print(dis.code_info(g.gi_code)) Name: <genexpr> Filename: <python-input-5> Argument count: 1 Positional-only arguments: 0 Kw-only arguments: 0 Number of locals: 2 Stack size: 2 Flags: OPTIMIZED, NEWLOCALS, GENERATOR Constants: 0: None Variable names: 0: .0 1: xОн имеет один параметр — итератор, равный iter(range(10)) для нашего g. Внутри генераторной функции переданный итератор попадает в локальную переменную '.0'. Такое название — внутренняя деталь реализации CPython. Получается, что вместо iter(range(10)) в генераторное выражение попал range(20). Важно: не iter(range(20)), а range(20), т.к. именно его мы непосредственно указали в коде. Можете проверить, что в варианте iter(range(20)) никакого crash не будет, list(g) просто будет списком чисел от 0 до 19.
Итак, проблема в том, что вместо объекта итератора внутрь генераторной функции «пролез» объект range, который является Iterable, но не является итератором.
Как исправить?
Падение интерпретатора Python — это нехорошо, подумал я, и создал issue. Сообщество СPython — очень живое и отзывчивое. Вероятно, поэтому в тот же день я получил ответ Jelle Zijlstra — одного из Core Developers. В нем он указал причину проблемы и предложил решение: добавить NULL-check в Си-код в нужное место. Чуть позже именно это решение было отклонено Mark Shannon — разработчиком CPython, много лет занимающимся виртуальной машиной — как недостаточно эффективное. Замечу, что в своё время Mark защитил PhD-работу про виртуальные машины.
Тем не менее, в результате совместного обсуждения подходящее решение было выработано, мой PR принят и влит в main, а также произведён его backport в ветку 3.13. Так что на ближайшей версии 3.13.1, которая выйдет в ноябре, этого падения не будет. А код изначального теста будет работать одинаково и для range(20), и для iter(range(20)).
В Python 3.13 изменения этим и ограничатся, а на будущих версиях поменяется поведение кода при создании заведомо некорректных генераторных выражений. Например, таких:
>>> (x for x in 42) Traceback (most recent call last): File "<python-input-7>", line 1, in <module> (x for x in 42) ^^ TypeError: 'int' object is not iterableЭта ошибка больше выдаваться не будет, но аналогичная по сути ошибка проявится позже, в момент итерирования полученного генератора. Этих изменений в ветке main ещё нет, идет работа над Pull Request.
Альтернативные варианты модификации генераторов
Получается, это всё касается только версии Python 3.13? И да, и нет. Именно такой код в более ранних версиях Python сработает по-другому: изменится только значение внутри объекта f_locals, но не настоящее значение локальной переменной с именем '.0'. Поэтому вторая строка не сделает ничего существенного. Но можно придумать и другие способы. Например, такой:
g = (x for x in range(10)) import types g_fn = types.FunctionType(g.gi_code, {}) g = g_fn(range(20)) list(g)Или такой:
g = (x for x in range(10)) g_fn = lambda it: None g_fn.__code__ = g.gi_code g = g_fn(range(20)) list(g)По сути, всё это вариации на тему одной и той же идеи: получить генератор, у которого тот же самый code object, но другой «нижележащий итератор».
Бонус первый
Наряду с генераторными выражениями в Python есть и другие похожие конструкции. Речь о comprehensions: listcomp, setcomp, dictcomp. Можно задаться вопросом: а они тоже внутри себя делают какой-нибудь code object и потом его вызывают? Оказывается, раньше так и было, но, начиная с Python 3.12, comprehension встраиваются в код и не имеют stack frame, детали можно узнать из PEP 709.
В качестве демонстрации отсутствия code object покажу байт-код для listcomp:
>>> dis.dis('[x for x in range(10)]') 0 RESUME 0 1 LOAD_NAME 0 (range) PUSH_NULL LOAD_CONST 0 (10) CALL 1 GET_ITER LOAD_FAST_AND_CLEAR 0 (x) SWAP 2 L1: BUILD_LIST 0 SWAP 2 L2: FOR_ITER 4 (to L3) STORE_FAST_LOAD_FAST 0 (x, x) LIST_APPEND 2 JUMP_BACKWARD 6 (to L2) L3: END_FOR POP_TOP L4: SWAP 2 STORE_FAST 0 (x) RETURN_VALUE -- L5: SWAP 2 POP_TOP 1 SWAP 2 STORE_FAST 0 (x) RERAISE 0 ExceptionTable: L1 to L4 -> L5 [2]Бонус второй
Даже после внесения фикса в main поведение интерпретатора можно улучшать с точки зрения читаемости. Так, если в качестве «нижележащего итератора» указать заведомо некорректное значение, то выпадет TypeError, текст которого не совсем корректен:
>>> g = (x for x in range(10)) >>> g.gi_frame.f_locals['.0'] = 42 >>> list(g) Traceback (most recent call last): File "<python-input-2>", line 1, in <module> list(g) ~~~~^^^ File "<python-input-0>", line 1, in <genexpr> g = (x for x in range(10)) ~~~~~^^^^ TypeError: 'int' object is not iterableВ идеале, TypeError должен указывать не на то место, где генераторное выражение создавалось, а на то, где оно изменялось через f_locals.
Бонус третий
А вы знали, что comprehension бывают сложными, составными, что они могут содержать несколько for, и каждый из них — несколько условий? Приведу пример подобного синтаксиса:
>>> [x**2 + 1000*y**2 for x in range(10) if x%2 == 0 for y in range(2*x) if y % 2 != 0 if x + y > 3 if x >= y] [1016, 9016, 1036, 9036, 25036, 1064, 9064, 25064, 49064]Как вы думаете, можно ли совмещать for и async for в одном comprehension? И зачем это может быть нужно? Пишите свои идеи в комментарии, обсудим! (А тут можно почитать про построение do-нотации на их основе).
Завершение
Благодарю за идею этой статьи и помощь в подготовке Никиту Соболева. Заглядывайте в его телеграмм-канал, там много похожего контента про кишки питона!
Если статья понравится аудитории, возможны продолжения на смежные темы. Спасибо за внимание!
ссылка на оригинал статьи https://habr.com/ru/articles/853864/
Добавить комментарий