http://habrahabr.ru/post/264609/



От переводчика: Наверно всем интересно, что внутри у инструмента, который используешь, этот интерес овладел и мной, но главное не утопать в нём и не закопаться так что не вылезти. Найдя для себя интересный материал, я решил заботливо перевести его и представить хабросообществу (моя первая публикация, прошу ногами сильно не пинать). Тем, кому интересен как Python работает на самом деле, прошу проследовать под кат.

Последние три месяца я потратил много времени на byterun, интерпретатор питоновского байткода, написанного на питоне. Работа над этим проектом была для меня захватывающе весёлой и познавательной. Я был бы рад, если бы вы тоже его потыкали. Но прежде нам надо немного остепенится, понять как работает python, так, чтобы мы знали, что такое интерпретатор на самом деле и с чем его едят.

Я подразумеваю, что вы сейчас в том же положении, что и я три месяца назад. Вы понимаете python, но понятия не имеете как он работает.

Небольшая заметка: Я работаю с версией 2.7 в этом посте. Третья версия почти схожа со второй, есть небольшие различия в синтаксисе и наименованиях, но в целом всё тоже самое.

Как работает python?

Мы начнём с очень (очень очень) высокого уровня внутренней работы. Что происходит когда вы выполняете код в вашем интерпретаторе?

~ $ python
Python 2.7.2 (default, Jun 20 2012, 16:23:33)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "hello"

Годы идут, ледянки тают, Линус Торвальдс пилит очередное ядро, а 64 битый процессор без устали трудится, тем временем происходит четыре шага: лексической анализ, парсинг, компиляция и наконец таки интерпретация. Парсер забирает скормленные ему инструкции и генерирует структуру которая объясняет их связь формируя AST( Абстрактное Синтаксическое Дерево). Компилятор затем преобразует AST в одни (или несколько) объектов кода (байткод + обвязка). Потом интерпретатор выполняет каждый объект.

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

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

Объекты функции

Вы наверно могли слышать про «объекты функции». Это вещи которые люди подразумевают когда говорят: «Функции — это объекты первого класса». Давайте изучим их подробнее:

>>> def foo(a):
...     x = 3
...     return x + a
...
>>> foo
<function foo at 0x107ef7aa0>

«Функции это объекты первого класса» означает что функции — это объекты также как список это объект или экземпляры MyObject это объекты. Раз foo это объект, мы можем исследователь его не выполняя его (в этом и есть разница между foo() и foo). Мы можем предать foo как параметр в другую функцию или можем присвоить его переменной.

Давайте немного посмотрим на foo подробней:

>>> def foo(a):
...     x = 3
...     return x + a
...
>>> foo
<function foo at 0x107ef7aa0>
>>> foo.func_code
<code object foo at 0x107eeccb0, file "<stdin>", line 1>

Как вы можете видеть в выше приведённом коде, объект кода это атрибут объекта функции. Объект кода генерируется питоновским компилятором и интерпретатором, он содержит информацию необходимую для работы интерпретатора. Давайте посмотрим на атрибуты объекта кода:

>>> dir(foo.func_code)
['__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__',
'__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__', 'co_argcount', 'co_cellvars', 'co_code', 'co_consts', 'co_filename',
'co_firstlineno', 'co_flags', 'co_freevars', 'co_lnotab', 'co_name', 'co_names', 'co_nlocals',
'co_stacksize', 'co_varnames']

Здесь целая куча ништяков, большинство из которых нм сейчас не нужно. Давайте подробнее рассмотрим три атрибута объекта foo.

>>> foo.func_code.co_varnames
('a', 'x')
>>> foo.func_code.co_consts
(None, 3)
>>> foo.func_code.co_argcount
1

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

>>> foo.func_code.co_code
'd\x01\x00}\x01\x00|\x01\x00|\x00\x00\x17S'

Напоминаю что байткод и объекты кода это не одно и тоже. Байткод это атрибут объекта кода помимо многих других атрибутов. Так что же такое байткод? Ну это просто набор байт. Они выглядят странно когда мы их печатаем потому что некоторым байтом сопоставимы символы а другим нет, давайте выведем их как числа.

>>> [ord(b) for b in foo.func_code.co_code]
[100, 1, 0, 125, 1, 0, 124, 1, 0, 124, 0, 0, 23, 83]

Вот байты которые творят всю магию. Интерпретатор будет последовательно и безустанно выбирать байты, смотреть какие они операции выполняют и с какими аргументами и исполнять команды. Для того чтобы пойти ещё дальше можно просмотреть исходный код Cpython а конкретно ceval.c что мы сделаем позднее.

Дизассемблирование байткода

Дизассемблирование означает взять все эти байты и преобразовать их во что-нибудь, что мы человеки способны понять. Это не выполняется в стандартном цикле питона. Сегодня для этой задачи есть отличный инструмент — модуль dis. Мы воспользуемся функцией dis.dis чтобы проанализировать что делает наша foo.

>>> def foo(a):
...     x = 3
...     return x + a
...
>>> import dis
>>> dis.dis(foo.func_code)
  2           0 LOAD_CONST               1 (3)
              3 STORE_FAST               1 (x)

  3           6 LOAD_FAST                1 (x)
              9 LOAD_FAST                0 (a)
             12 BINARY_ADD
             13 RETURN_VALUE

Первый номер это строка исходного python кода, второй номер это смещение внутри байткода: LOAD_CONST находится на позиции 0, а STORE_FAST на позиции 3 и так далее. Средняя колонка это название самой инструкции, последние две колонки дают понятие об аргументах инструкции (ели они есть), четвертая колонка показывает сам аргумент, который представляет собой индекс в других атрибутов объекта кода. В этом примере аргумент для LOAD_CONST это индекс в списке co_consts, а аргумент для STORE_FAST это индекс в co_varnames, в пятой колонке выводятся имена переменных или значение констант. Мы можем с легкостью это проверить:

>>> foo.func_code.co_consts[1]
3
>>> foo.func_code.co_varnames[1]
'x'

Это также объясняет вторую инструкцию STORE_FAST которая находится по позиции 3 в байткоде. Если инструкция имеет аргумент следующие два байта и есть этот аргумент. Работа интерпретатора как раз таки в том чтобы не запутается и продолжать сеять разумное, доброе, вечное. (вы могли заметить что BINARY_ADD не имеет аргументов, не волнуйтесь мы ещё вернемся к этому)

Была одна вешь которая удивляла меня когда я начел разбираться в том как работает python, как python может быть динамическим, если он ещё и «компилируется»? Обычно эти два слова «антонимы», есть динамические языки такие как Python, Ruby, и Javascript, а есть компилируемые таки как C, Java, и Haskell.

Когда люди говорят об компилируемых языках они имеют ввиду компиляцию в нативные x86/ARM/etc инструкции. Интерпретируемый язык не имеет компиляции вообще, разве что только «компилируется» на лету в байткод. Интерпретатор питона разбирает байткод и выполняет его внутри виртуальной машины, что кстати достаточно много работы, но мы поговорим об этом позднее.

Для того чтобы быть динамическим надо быть абстрактным, давайте посмотрим что это значит:

>> def modulus(x, y):
...     return x % y
...
>>> [ord(b) for b in modulus.func_code.co_code]
[124, 0, 0, 124, 1, 0, 22, 83]
>>> dis.dis(modulus.func_code)
  2           0 LOAD_FAST                0 (x)
              3 LOAD_FAST                1 (y)
              6 BINARY_MODULO
              7 RETURN_VALUE

Эта дизассемблированая функция в байткоде. К тому времени как мы получаем приглашение функция modus была скомпилирована и объект корда был сгенерирован. Достаточно внезапно, но операция остатка от деления % (операция modulus) преобразуется в BINARY_MODULO. Похоже этой функцией можно воспользоваться для чисел:

>>> modulus(15,4)
3

Неплохо, а что если мы передадим что то другое, например строку.

>>> modulus("hello %s", "world")
'hello world'

Опана, что это тут? Вы наверно уже видели это раньше:

>>> print "hello %s" % "world"
hello world

Когда операция BINARY_MODULO выполняется для двух строк она выполняет подстановку строк вместо остатка от деления. Эта ситуация отличный пример динамической типизации. Когда компилятор генерирует объект кода для modulus он не имеет понятия что такое x и y, строки ли они или числа или что-то ещё. Он просто выполняет инструкции: загрузить одну перемененную, загрузить другую, выполнять препарацию бинарного модуля, вернуть результат. Работа интерпретатора в том чтобы понимать что BINARY_MODULO значит в текущем контексте. Наша функция modulus может считать остаток, подставлять строки… может что-то ещё? Если мы определим класс с методом __mod__ то мы сможем сделать что угодно.

>>> class Surprise(object):
...     def __init__(self, num):
...         self.num = num
...     def __mod__(self, other):
...         return self.num + other.num
...
>>> seven = Surprise(7)
>>> four = Surprise(4)
>>> modulus(seven, four)
11
>>> modulus(7,4)
3
>>> modulus("hello %s", "world")
'hello world'

Одна и та же функция с одним и тем же байткодом может выполнять разные операции в зависимости от типа контекста. Также функция modulus может возбудить исключение для примера TypeError если мы вызовем его для объектов, которые не реализованы.

Это является одной из причин того, почему трудно оптимизировать python. Вы не знаете, когда вы генерируете код объекта и байт-код, что за объекты будут в конечном итоге. Russell Power и Alex Rubinsteyn написали статью «как быстр может быть python», это статья достаточного содержательная.

На сегодня пока все. Оригинал статьи тут. Прошу прошения за возможные ошибки т.к. от природы обладаю врождённой безграмотностью и вынужден пользоваться машинным способом проверки текста.