— Меня зовут Александр, я в Яндексе работаю программистом. Пишем мы в моей команде на Python, на Go пока не перешли. Но в свободное от работы время я, как ни странно, тоже программирую и делаю это на очень динамическом языке — Common Lisp. Он, пожалуй, даже более динамический, чем Python. Его особенность заключается в том, что сам процесс разработки устроен несколько иначе. Он более интерактивный и итеративный, потому что в REPL на Lisp вы можете делать всё: создавать новые и удалять старые модули, добавлять методы, классы и удалять их, переопределять классы и т. д.



В Python с этим все более сложно. В нем есть IPython. Конечно, IPython некоторым образом улучшает REPL, добавляет автодополнение, позволяет использовать разные расширения. Но для итеративной разработки он подходит не очень хорошо. В нем можно загрузить код, немножечко его потестить и всё. А иногда от него хочется большего интерактива, чтобы можно было реально использовать этот REPL в разработке, переключаться между модулями, менять функции и классы внутри них.

У меня такое бывает — запускаешь, например, IPython REPL в продакшен-среде и начинаешь там какие-нибудь команды запускать, что-то исследовать, а потом обнаруживается, что в модуле ошибка, и хочется ее по-быстрому поправить. Но так сделать не получается, потому что нужно собрать новый Docker-образ, выкатить его в продакшен, снова зайти в этот REPL, снова добиться там нужного состояния, снова запустить то, на чем все упало. А в идеале я должен был бы поправить функцию, тут же ее запустить и мгновенно получить результат.

Что можно с этим сделать? Каким образом в IPython можно перезагрузить код? Я пробовал использовать autoreload, и мне не понравилось по нескольким причинам. В первую очередь, он при перезагрузке модуля теряет состояние, которое внутри этого модуля было в глобальных переменных. А там может быть закешированное значение с результатами каких-то функций. Или я мог, например, подгрузить там данные по сети, чтобы потом с ними быстрее работать. То есть autoreload теряет состояние.

Поэтому в качестве эксперимента я сделал свое простое расширение для IPython и назвал его TheREPL.

Я к вам с этим докладом пришел как с идеей того, что можно сделать с REPL в Python. И очень надеюсь, что вам эта идея понравится, вы унесете ее в головах и будете дальше придумывать штуки, которые позволят сделать Python еще более эффективным и удобным.

Что же такое TheREPL? Это расширение, которое вы загружаете, после этого в IPython появляется такое понятие как namespace, и вы можете взять и переключиться в любой питоновский модуль, посмотреть, какие там есть переменные, функции и так далее. И что более важно — можно прямо написать def, название функции, переопределить функцию или класс, и он поменяется во всех модулях, куда был импортирован. Но при этом перезагрузки самого модуля не происходит, поэтому состояние сохраняется. Кроме того, TheREPL позволяет избежать еще некоторых артефактов, которые есть в autoreload и на которые мы сейчас посмотрим.



Итак, в autoreload апгрейд кода происходит только при сохранении файла. Но при этом нужно ввести что-то в сам REPL, и только тогда autoreload подхватит эти изменения. Это проблема №1. То есть, если у вас какой-то фоновый процесс в отдельном потоке (например, сервер работает), вы не можете просто так взять и поправить код. Autoreload не применит эти изменения до тех пор, пока вы в IPython REPL что-нибудь не введете.

В случае моего расширения вы прямо в редакторе нажимаете шоткат, и функция, которая находится под курсором, тут же применяется и начинает работать. То есть с помощью TheREPL можно более гранулярно менять код. Кроме того, можно в IPython тоже написать def.



Переключение между модулями, как я сказал, autoreload никаким образом не поддерживает. Вы можете только найти файлик в файловой системе, поменять его и надеяться, что autoreload там все разрулит.



Дальше. Autoreload теряет глобальные переменные, TheREPL сохраняет и позволяет вам продолжать исследовать работу своего приложения, менять его внутренний код и таким образом разрабатывать его быстро.



У autoreload есть еще такая особенность. Он очень хитро применяет изменения в том модуле, который перезагружает. В частности, он делает там очень интересный трюк. Если функция в этом модуле обновилась, то чтобы ее поменять везде, где она была проимпортирована, он с помощью сборщика мусора находит ее и все эти экземпляры функций и внутри них меняет код. Дальше мы посмотрим на примерах, как это происходит. Благодаря этому код функции меняется, даже если она попала в замыкание.

Вы знаете, что такое замыкание? Это очень полезная штука. JavaScript-разработчики постоянно этим пользуются. Вы, скорее всего, тоже, просто никогда не обращали внимания. Но поскольку autoreload делает то, что я описал выше, вы можете оказаться в ситуации, когда старый код использует новый код, который может работать по-другому. Например, функция может возвращать не одно значение, а два, tuple вместо string и т. д. Старый код на этом сломается.

TheREPL такой хитрой штуки не делает специально для того, чтобы всё было более консистентно. То есть он меняет функцию или класс в модуле, в котором она определена. Находит этот класс, во всех остальных модулях, и там тоже меняет. После этого все работает уже по-новому.



Как работает замена функции, которую делает autoreload? У нас есть две функции, one и two. В каждой функции есть набор атрибутов: документация, код, аргументы и т.д. Здесь на слайде показан пример замены атрибутов, в которых хранится байт-код.

После того, как autoreload его поменяет, вызванная функция начинает работать уже по-другому. Но это синтетический пример, который я просто воспроизвел руками, чтобы вы понимали, что происходит. Функция называется одним образом, но код там на самом деле другой. И если дизассемблировать, там тоже видно, что она возвращает двойку. К чему это приводит?



Вот пример замыкания. На второй строчке мы создаем замыкание, в которое захватываем функцию foo. Само замыкание ожидает, что эта функция, которую мы передали, возвращает строчку, она ее кодирует в utf-8 и все работает.



Но предположим, вы поменяете модуль, в котором foo определена, и autoreload подхватит изменение. А поменяете вы ее так, чтобы она возвращала не строку, а число. Тогда замыкание уже будет работать неправильно, потому что функция в нем поменялась внутри, а замыкание этого не ожидает, оно же не изменилось. И такие проблемы с autoreload могут «выстреливать» в неожиданных местах.



Как autoreload обновляет классы? Очень просто. Он все методы класса обновляет точно так же, как функции, и еще он у всех инстансов обновляет атрибут __class__, чтобы резолюция методов (определение того, какой метод нужно вызвать), начала работать по-новому.

В TheREPL все чуточку сложнее, потому что когда вы обновляете _class_, может оказаться, что у него есть какие-то потомки, дочерние классы, которые тоже нужно обновить, поскольку в списке базовых классов что-то поменялось.

Чтобы решить эту проблему, можно перестроить класс. Но давайте для начала посмотрим, что происходит с autoreload, когда он перезагружает модуль.



Вот хороший пример. Есть два модуля — a и b. В модуле a определен родительский класс, в модуле b дочерний, и мы создаем инстанс дочернего класса. И на строчке 10 видно, что да, это инстанс класса Foo, родительского.



Дальше мы просто берем и меняем модуль a. Например, добавляем в класс Foo документацию. Затем autoreload подхватывает эти изменения. Как вы думаете, что он в этом случае вернет из Bar?



А он возвращает false, потому что autoreload поменял класс Foo, и теперь это совсем другой класс, не тот, от которого унаследован класс Bar.



И сюрприз! В двух модулях a и b класс Foo — это разный класс, и Bar наследуется от какого-то одного из них. Из-за таких косяков очень сложно предсказать, как будет работать ваш код после того, как autoreload в нем что-то поправит.



Примерно так он обновляет классы. Я прокомментирую картинку. Изначально класс Foo импортируется в модуль b и так там и остается. При замене autoreload релодит этот модуль a, и там появляется уже новый класс, а в модуле b он не обновляется.



TheREPL делает немного по-другому. Он инжектит измененный класс внутрь каждого модуля, куда он был проимпортирован. Поэтому там все работает корректно. Более того, если в классе были объекты, они сохранятся.



А вот так TheREPL решает проблему с дочерними классами. То есть когда поменялся родительский класс, он определяет список базовых классов через магический атрибут mro (method resolution order). Этот атрибут содержит список классов в том порядке, в котором нужно искать в них методы или атрибуты. И каждый раз, когда вы вызываете у своего объекта, например, метод get_name, Python пойдет сначала проверит его в классе Bar, потом в классе Foo, потом в классе object, если не найдет. Он действует согласно процедуре method resolution order.

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

Вы просто говорите имя класса, говорите, какой у него базовый класс. В простейшем случае, например, object. И — словарик с методами и атрибутами класса. Все, у вас появляется новый класс, который можно инстанциировать, как обычно. TheREPL пользуется этой фишкой. Он генерит дочерний класс и меняет на него указатели во всех объектах старого класса Bar.

У меня еще заготовлена демка, давайте взглянем, как это работает. Для начала посмотрим на такой простой штуке.