От исходника к байткоду: шесть шагов, которые Python делает до первой инструкции

Никто не исполняет ваш текст

Есть распространённая картинка: Python читает файл строку за строкой и делает то, что написано. Так работает не Python, а сильно упрощённый калькулятор.

На самом деле между вашим файлом и работой стоит переводчик. Он один раз читает текст целиком, разбирает его и выдаёт список коротких команд — таких, что каждая делает ровно одну простую вещь: «положи значение переменной», «возьми у объекта атрибут», «сложи два верхних значения».

Дальше исполняются уже команды. Текст больше никто не читает.

Шесть шагов переводчика

Переводчик работает не одним махом, а по шагам. Каждый шаг превращает материал во что-то другое.

• Текст. Просто строка символов.
• Слова. Текст режется на кусочки: def, f, (, a, ). У каждого запоминается, где он стоял — строка и колонка. Это пригодится в самом конце.
• Дерево. Список слов превращается в структуру: вот функция, у неё имя, список аргументов и тело, а в теле — возврат суммы.
• Список имён. Отдельный проход решает про каждое имя: оно своё, местное, или взято снаружи. Именно здесь, а не при исполнении.
• Уборка. Всё, что можно посчитать заранее, считается заранее; всё, до чего нельзя добраться, выбрасывается.
• Команды. То, что останется, и будет исполняться.

Переключайте вкладки на схеме ниже — там настоящий вывод каждого шага для одной маленькой функции.

Уборка бывает довольно щедрой

Некоторые вещи можно посчитать, ещё не запуская программу. Python это делает.

def g():
    return 2 + 3 * 4

В готовых командах никакого умножения нет — там сразу число 14. Умножение произошло один раз, при переводе.

Так же исчезают:

• код после return — до него всё равно не дойти;
• ветка if False: — вместе со всем, что внутри;
• соседние строки в кавычках: 'a' 'b' 'c' становится одной строкой 'abc'.

Отсюда практический вывод: выносить 2 + 3 * 4 в отдельную переменную «чтобы не считалось каждый раз» — работа впустую. Оно и так не считается.

Шесть команд, шестнадцать ячеек

Вот число, которое удивляет. Для одной строки

def f(a): return a.x + 1

получается шесть команд. А места они занимают как шестнадцать.

Десять ячеек пустые. Они оставлены про запас: пока программа работает, Python подсматривает, что происходит на самом деле — какого типа объект, где у него лежит нужный атрибут, — и записывает подсмотренное в эти ячейки. В следующий раз ту же работу можно не делать заново.

Больше всего запаса просит команда «возьми атрибут» — девять ячеек. Столько не просит ни одна другая команда: это самый большой запас во всей таблице.

Куда доезжают координаты слов

Помните, на втором шаге у каждого слова запомнили, где оно стояло? Это не бухгалтерия ради бухгалтерии.

def boom(a, b, c, d):
    return a.x + b.y * c.z - d.w

Если d окажется не тем, что ожидалось, Python покажет:

    return a.x + b.y * c.z - d.w
                             ^^^
AttributeError: 'NoneType' object has no attribute 'w'

Стрелочки стоят ровно под d.w — не под всей строкой, хотя в ней четыре обращения к атрибутам. Координаты, записанные в самом начале, доехали до конца и всплыли в момент ошибки.

Бесплатным это не бывает: файлы с готовыми командами для стандартной библиотеки выросли из-за этого на 22 %. Разработчики Python посчитали, что точная стрелочка того стоит.

Почему переменная бывает «уже локальной»

Тот самый шаг со списком имён объясняет знаменитую загадку:

x = 10
 
def f():
    print(x)   # UnboundLocalError
    x = 5

Кажется, что до x = 5 ещё не дошли, значит print(x) должен взять внешнюю x. Но решение о том, местная переменная или внешняя, принимается не при исполнении, а на четвёртом шаге — при переводе, когда переводчику видно всю функцию целиком.

Есть присваивание где-нибудь в теле — значит имя местное во всей функции, включая строки выше присваивания. Спорить с этим при исполнении уже некому.

Три вещи, которые стоит запомнить

Перевод происходит один раз. Не при каждом вызове функции, а при загрузке файла.

Часть работы делается заранее. Арифметика на константах, склейка строк, выброс недостижимого кода — всё это до старта.

Пустые ячейки — не расточительство, а рабочее место. Именно в них интерпретатор складывает то, что подсмотрел, чтобы во второй раз работать быстрее.

Зачем это знать?

Почти всё, что дальше происходит при исполнении, опирается на объект кода. Пока не видно, что инструкций больше, чем строк, а ячеек больше, чем инструкций, разговор про специализацию и кеш атрибутов вести не на чем: специализируется именно инструкция, а кеш живёт именно в этих ячейках.

Есть и практическая сторона. Отсюда становится понятно, почему UnboundLocalError случается там, где переменная «вроде бы есть»; почему трассировка в 3.11+ показывает указатель ровно под нужным подвыражением; и почему одинаковый на вид код иногда компилируется в разное число инструкций.

Начать честно стоит с предупреждения, которым открывается документация dis:

Всё ниже — про CPython и про конкретные версии. Ни одно из этих чисел не является частью языка.

Модель в голове

Компилятор Python — это конвейер, а не одна функция. Текст проходит шесть станций, и на каждой из них он перестаёт быть тем, чем был.

1. Текст — строка байтов.
2. Токены — слова с координатами.
3. Дерево — структура вместо последовательности.
4. Таблица символов — кто здесь локальный, а кто глобальный.
5. Граф и оптимизации — то, что можно выбросить, выбрасывается.
6. Объект кода — то, что исполняется.

Шаг 3 с версии 3.9 делает PEG-парсер вместо прежнего LL(1) (PEP 617) — после этой замены грамматика перестала быть ограничением языка.

Ключевое свойство конвейера: координаты из шага 2 доезжают до шага 6. Номер строки и колонки, записанные при токенизации, попадают в объект кода и через годы всплывают в трассировке как указатель под нужным символом.

Четыре из шести шагов показывает отдельный модуль: tokenize, ast, symtable, dis; текст — это просто файл. Пятый, граф потока управления, из Python наблюдается только косвенно — и это стоит сказать прямо, а не нарисовать «примерную схему».

Граф — это тело функции, разрезанное на куски без ветвлений, со стрелками переходов между ними. По нему компилятор и видит, что недостижимо и что можно свернуть. Сам граф наружу не выставлен; единственная щель — флаг ast.PyCF_OPTIMIZED_AST, появившийся в 3.13, и про неё в разделе про два прохода.

Что реально видно на каждом шаге

Токены даёт tokenize. Четырнадцать штук на одну строку, и у каждого — пара координат. Именно эти координаты — предмет PEP 657.

Дерево даёт ast.parse. Обратите внимание на ctx=Load() у Name и Attribute: чтение и запись различаются уже здесь, задолго до байткода. Из этого различия потом вырастут разные опкоды.

Таблицу символов даёт symtable — модуль, о котором мало кто помнит, хотя он показывает самый неочевидный проход компилятора. Отдельный обход дерева, целиком до генерации кода, решает про каждое имя: локальное, глобальное, захваченное из внешней области. У нашей функции:

>>> st = symtable.symtable("def f(a): return a.x + 1", "<s>", "exec")
>>> f = st.get_children()[0]
>>> f.get_parameters()
('a',)
>>> [(s.get_name(), s.is_local(), s.is_parameter()) for s in f.get_symbols()]
[('a', True, True)]

Вот отсюда, а не из рантайма, берётся LOAD_FAST вместо LOAD_GLOBAL. И отсюда же — UnboundLocalError. Это можно не рассказывать, а показать:

x = 10
 
def f():
    print(x)   # UnboundLocalError
    x = 5

>>> st = symtable.symtable(open("unbound.py").read(), "unbound.py", "exec")
>>> for s in st.get_children()[0].get_symbols():
...     print(s.get_name(), s.is_local(), s.is_global())
print False True
x     True  False

x помечена локальной на этапе разбора, до единой исполненной строки — и помечена во всей функции сразу, включая print(x) выше присваивания. Спорить с этим при исполнении уже некому:

  File "unbound.py", line 4, in f
    print(x)
          ^
UnboundLocalError: cannot access local variable 'x' where it is not associated with a value

Заодно видно, что print в той же таблице помечен как is_global. Отсюда разные опкоды — и старый совет «положи встроенную функцию в локальную переменную перед горячим циклом». Совет проверяемый, так что проверим (3.13.7, минимум из семи прогонов по 2 000 000 вызовов):

1,36 нс, около 10 %. Разница есть и она воспроизводима — но это тот случай, когда правильный вывод из числа противоположен ожидаемому: приём, который передаётся как заметная оптимизация, экономит 1,36 нс на вызов. Ради него портить читаемость незачем.

Объект кода: шесть инструкций и шестнадцать ячеек

Теперь главное число статьи.

>>> def f(a): return a.x + 1
>>> len(list(dis.get_instructions(f)))
6
>>> len(f.__code__.co_code) // 2
16

Шесть и шестнадцать. Разница — не ошибка и не выравнивание: десять ячеек занимает inline-кеш, место, которое инструкция резервирует под собственные данные о том, что она уже видела.

LOAD_ATTR резервирует девять ячеек, BINARY_OP — одну. Посмотреть таблицу целиком можно не читая исходники:

>>> import opcode
>>> {k: v for k, v in sorted(opcode._inline_cache_entries.items()) if v}
{'BINARY_OP': 1, 'BINARY_SUBSCR': 1, 'CALL': 3, 'COMPARE_OP': 1, ...
 'LOAD_ATTR': 9, 'LOAD_GLOBAL': 4, 'STORE_ATTR': 4, 'TO_BOOL': 3, ...}

Это подчёркивание в имени — предупреждение: приватное поле, из версии в версию меняется. Что и происходит: в 3.14 у BINARY_OP там уже 5.

Почему это важно за пределами арифметики. Специализация — тема следующей статьи — работает так, что инструкция переписывает саму себя в специализированный вариант и складывает наблюдения в эти самые ячейки. Пока неизвестно, что ячейки существуют, механизм специализации выглядит магией.

Координаты, которые доехали до конца

PEP 657 добавил в объект кода четыре числа на инструкцию: начало и конец строки, начало и конец колонки. Видно через co_positions(), а работает так:

class O: pass
 
def boom(a, b, c, d):
    return a.x + b.y * c.z - d.w
 
o = O(); o.x = 1; o.y = 2; o.z = 3
boom(o, o, o, None)

На 3.12.3:

  File "pep657.py", line 4, in boom
    return a.x + b.y * c.z - d.w
                             ^^^
AttributeError: 'NoneType' object has no attribute 'w'

Указатель стоит под d.w, а не под всей строкой — хотя в строке четыре обращения к атрибутам и три операции. Это те самые координаты, записанные при токенизации.

На 3.13.7 в той же программе указатели появляются и на строке вызова:

    boom(o, o, o, None)
    ~~~~^^^^^^^^^^^^^^^

Цена названа в самом PEP и не спрятана: pyc-файлы стандартной библиотеки выросли на 22 %, с 28,4 до 34,7 МБ. За точность трассировки платят диском и памятью, и это осознанный размен.

Что делает оптимизатор

Сам граф потока управления из Python не виден: он живёт внутри compile.c, между _PyAST_Compile (строка 442 на теге v3.13.7) и optimize_and_assemble (строка 7689), и наружу не выставлен. Единственная щель появилась в 3.13 — про неё в разделе про два прохода ниже.

Зато его следствия измеримы полностью. Всё ниже — настоящий co_consts и настоящая цепочка опкодов на 3.13.7:

NOP на месте вырезанного if — не мусор. PEP 626 требует, чтобы у каждой исполняемой инструкции был номер строки и чтобы строки, которые исполнялись, не пропадали из отладочной информации; NOP держит эту бухгалтерию.

Обратите внимание, чего в таблице нет: ни одной оптимизации, которая переставляла бы вычисления местами или выбрасывала обращение к атрибуту. Компилятор Python сознательно почти ничего не знает о значениях — всё интересное происходит позже, в интерпретаторе.

Что изменилось в 3.12, 3.13 и 3.14

Числа получены одним и тем же скриптом на одной и той же функции.

Ловушка в предпоследней строке. HAVE_ARGUMENT упал с 90 до 44, и легко прочитать это как «меньше инструкций стало принимать аргумент». Последняя строка показывает обратное: их стало больше, 101 → 107. HAVE_ARGUMENT — это просто граница в нумерации опкодов, и её сдвиг означает, что нумерацию переразложили, а не что что-то упростилось. Число, которое само по себе ничего не значит, — хороший повод не доверять однострочным сравнениям версий.

Строка «опкодов в языке» — из того же семейства: число измерено, но что именно добавилось в opcode.opname к 3.14, по нему не видно, и я это не проверял.

Про co_consts в 3.14. Он стал (1,) вместо (None, 1), а в дизассемблере вместо LOAD_CONST стоит LOAD_SMALL_INT. Долгое время здесь стояло признание, что причина не прочитана. Теперь она разобрана — в разделе про два прохода ниже, и объясняется она не одной причиной, а двумя сразу.

Про документацию. У компилятора CPython есть внутренняя документация — InternalDocs/compiler.md, code_objects.md, parser.md. Проверено запросами к обоим тегам: на v3.14.0 все три отдают 200, на v3.13.7 — 404. В 3.13 каталог InternalDocs/ содержит ровно один файл, string_interning.md. То есть статья про компилятор 3.13 обязана читать код, а не документ, и любая ссылка на InternalDocs/compiler.md применительно к 3.13 — ссылка на то, чего нет.

Оптимизаторов два, и в 3.14 они поменялись работой

Сказанное выше — «пятый шаг не виден из Python вовсе» — с 3.13 перестало быть точным, и различие стоит того, чтобы его знать.

Проходов на самом деле два, и внутренняя документация компилятора перечисляет их отдельными шагами:

До шага 3 работает ещё один проход — по самому дереву. На 3.13 он живёт в Python/ast_opt.c, на 3.14 файла с таким именем нет вовсе, а его место занял Python/ast_preprocess.c, про который та же документация говорит коротко: Preprocesses the AST before compiling (Предобрабатывает AST перед компиляцией). Переименование не косметическое.

Разделить два прохода наблюдением можно ровно одним способом — флагом ast.PyCF_OPTIMIZED_AST, добавленным в 3.13. Он возвращает дерево уже после прохода по AST и ещё до генерации инструкций (bench/source-to-bytecode/optimizer_passes.py).

3.13.7   дерево после прохода по AST:
   константная арифметика   Return(value=Constant(value=14))

3.14.7  то же дерево:
   константная арифметика   Return(value=BinOp(left=Constant(value=2), op=Add(),
                              right=BinOp(left=Constant(value=3), op=Mult(), right=Constant(value=4))))

На 3.13 2 + 3 * 4 свёрнуто до генерации инструкций. На 3.14 проход по AST не свернул ничего, а в байткоде всё равно стоит LOAD_SMALL_INT 14: свёртка произошла позже, на графе. Это подтверждается и кодом — в v3.14.0 у fold_binop в ast_preprocess.c осталась одна-единственная ветка (% со строкой слева), а в flowgraph.c появились fold_const_binop и fold_const_unaryop, которых на v3.13.7 там нет ни одного вхождения. Ограничители переехали дословно, теми же именами и значениями: MAX_INT_SIZE 128, MAX_COLLECTION_SIZE 256, MAX_STR_SIZE 4096, MAX_TOTAL_ITEMS 1024.

Что за проходом по AST осталось на 3.14. Он не исчез, а сузился до преобразований формы дерева: '%s' % (x,) по-прежнему становится JoinedStr, список в in по-прежнему превращается в кортеж. А вырезание недостижимого блока было работой графа на всех трёх версиях. С not not x → TO_BOOL осторожнее: на 3.12 он не сворачивался вовсе — в байткоде стоят два UNARY_NOT, — да и самого TO_BOOL там ещё нет, он появился в 3.13.

И то, что этот переезд наконец объясняет. Выше в разделе про версии сказано, что в 3.14 co_consts стал (1,) вместо (None, 1), и причина не была объяснена. Теперь она видна: на 3.14 в таблице констант остаются значения, на которые не смотрит ни одна инструкция.

3.14.7, константы-сироты:
   константная арифметика  co_consts=(2,)               лишнее: (2,)
   унарный минус           co_consts=(5, -5)            лишнее: (5,)
   умножение строки        co_consts=('a', 'aaaa…')     лишнее: ('a',)
   мёртвая ветка           co_consts=(False, 'always')  лишнее: (False,)

3.12.3 и 3.13.7: нет ни одной

Строк с сиротами скрипт печатает девять; выше приведены четыре. Это ровно то, чего следует ждать, если таблица констант заполняется при генерации инструкций, а свёртка идёт после неё, на графе: свёрнутый операнд остаётся в таблице сиротой. Второй половиной объяснения служит LOAD_SMALL_INT, которому co_consts не нужен вовсе, — отсюда и (1,) вместо (None, 1).

Границы свёртки при этом переезд не сдвинул: 'a' * 4096 сворачивается, а 'a' * 4097 нет; 2 ** 64 да, 2 ** 65 нет; (1, 2) * 128 да, (1, 2) * 129 нет — одинаково на 3.12, 3.13 и 3.14.

Чего мы не выясняли: по какой причине свёртку решили перенести. Факт снят запуском и сверен с кодом на трёх тегах; обсуждения, где это решалось, мы не искали, и объяснения «зачем» здесь нет.

Что с этим делать

Не считайте инструкции по выводу dis. Он показывает шесть там, где в памяти шестнадцать ячеек. Для «сколько занимает сам байт-код» есть len(co_code), для «сколько занимает сама структура объекта кода, без того, на что она ссылается» — sys.getsizeof.

Не сравнивайте версии по одному числу. HAVE_ARGUMENT — живой пример величины, которая изменилась вдвое, не изменившись по смыслу.

Не оптимизируйте то, что уже свернул компилятор. 2 + 3 * 4, соседние строковые литералы, кортежи из констант, not not — всё это уже одна константа или одна операция. Выносить их в переменную «для скорости» — работа впустую.

Помните, что имена решаются до исполнения. Присваивание где угодно в теле функции делает имя локальным на всю функцию — это решение таблицы символов, а не рантайма. Отсюда UnboundLocalError в строке, которая стоит до присваивания.

И главное. Те десять пустых ячеек — не накладные расходы, а рабочее место. Заполняет их специализирующий интерпретатор — тот самый механизм, ради которого ячейки и зарезервированы.

Чем измерено

Числа этой статьи получены этим скриптом. Он открывается прямо отсюда — вместе с записью прогона: на чём считали, что получилось и с каким разбросом.

• bench/bytecode_bench.py
• bench/source-to-bytecode/optimizer_passes.py