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

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

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

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

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

Шесть станций конвейера

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

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

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

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

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

Некоторые вещи можно посчитать, ещё не запуская программу. 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 подсматривает, что происходит на самом деле — какого типа объект, где у него лежит нужный атрибут, — и записывает подсмотренное в эти ячейки. В следующий раз ту же работу можно не делать заново.

Больше всего запаса просит команда «возьми атрибут» — девять ячеек. Это не случайность: обращение к атрибуту в 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. Объект кода — то, что исполняется.

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

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

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

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

Токены даёт 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 %. Разница есть и она воспроизводима — но это тот случай, когда правильный вывод из числа противоположен ожидаемому: приём, который передаётся как заметная оптимизация, стоит полторы наносекунды на вызов. Ради него портить читаемость незачем.

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

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

>>> 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), и наружу не выставлен.

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

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

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

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

Числа получены одним и тем же скриптом (bench/bytecode_bench.py) на одной и той же функции.

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

Что честно не объяснено. В 3.14 co_consts стал (1,) вместо (None, 1), а в дизассемблере вместо LOAD_CONST стоит LOAD_SMALL_INT. Факт измерен; причину в flowgraph.c я не прочитал, поэтому объяснения здесь нет. Если встретите статью, которая уверенно объясняет это в двух словах, — стоит проверить, откуда взято.

Про документацию. У компилятора 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 — ссылка на то, чего нет.

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

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

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

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

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

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