Создаем свой диалект змеиного, или DSL на Python

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

Мы, как разработчики ядра, хотим, с одной стороны, спрятать всё «грязное белье» за неким интерфейсом, с другой — максимально упростить взаимодействие пользователей с ядром.

Как один из вариантов решения предлагаю посмотреть создание своего диалекта Python-скриптов, предназначенного для конкретной предметной области. Этакий DSL «для бедных», с синтаксисом Python, но со средой выполнения, заточенной под выполняемые задачи.

Я — Первушин Дмитрий, разработчик в управлении по развитию бэк-офиса торговых точек сети «Магнит». Основной стек – Python, Firebird, немного HTML/JS и капелька других технологий. Моя команда занимается разработкой приложений для терминалов сбора данных, отчетов, АРМ торговых точек. В этот раз хочу рассказать, как встроить пользовательские сценарии в приложение на Python.

Доступная палитра

Навскидку видно как минимум три варианта:

• обычный импорт;

• инъекция зависимостей через фабричный метод или класс;

• инъекция зависимостей напрямую в пространство имен.

Обычный импорт

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

# Импорт в скрипт необходимых объектов из ядра
from exec_core import reader, writer

# Используем объекты ядра для реализации бизнес-логики
x = reader()
writer(x / 0.87)

В этом подходе сразу три жирных минуса:

• Мы привязываемся к конкретной реализации сервиса, что допустимо только в случае, если она единственная и неизменяемая.

• Пользователь вынужден каждый раз повторять заклинание импорта.

• Пользователь должен знать устройство ядра и постоянно использовать это знание, что приводит к трудностям при рефакторинге ядра.

Инъекция зависимостей через фабричный метод или класс

Можно сделать «магический» объект, которому ядро будет поставлять реализации абстрактных интерфейсов, тогда получится примерно так:

def entry_point(reader, writer):
    """Ядро импортирует скрипт и вызовет эту функцию с конкретными реализациями сервисов."""
    x = reader()
    writer(x / 0.87)

Тут мы избавились от импорта и привязки к реализации: reader может читать откуда угодно, не требуя изменения скрипта. Минус два минуса. Но другие минусы все еще с нами:

• Ядро должно активно использовать интроспекцию, чтобы правильно вызвать функцию пользователя.

• Пользователь должен знать сигнатуры магической функции.

Инъекция зависимостей глобальное пространство имен

Если инъекцию зависимостей сделать через глобальное пространство имен, то получим такой скрипт:

"""При импорте ядро производит инъекцию в глобальные переменные,
со стороны скрипта никаких действий не требуется"""

x = reader()
writer(x / 0.87)

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

Реализация движка

Скелет

Сердцем скриптового движка будут встроенные функции compile и exec. Для начала нужно из текстового вида скрипта получить «объект кода» — скрипт, разобранный до состояния байт-кода. Делаем это вызовом compiled = compile (body, script_file_name, "exec", dont_inherit=True), где:

• body – строка с исходным текстом скрипта.

• script_file_name – путь к файлу скрипта. Если указать реальный файл, то в качестве бонуса получите понятные стектрейсы и поддержку отладки – точки останова, пошаговое выполнение.

• "exec" – режим компиляции «у нас много операторов». Альтернатива "eval" – «у нас единственное выражение» — в данном случае не подходит, хотя кому-то может пригодиться.

• dont_inherit – не наследовать «настройки будущего» (from __future__ import …) из модуля ядра. Оставим это на усмотрение автора скрипта.

У нас есть код, теперь нужно окружение, в котором этот код будет выполняться. Окружение обязано быть обычным словарем, никакие другие типы не допускаются. Заполняем его методами ядра, доступными из скрипта, и координатами исходников:

runtime={
    "__file__": script_file_name,
    "__name__": os.path.splitext(os.path.basename(script_file_name))[0],
    "reader": lambda : float(input("Enter a number, please:")),
    "writer": print,
}

Если не указать ключ "__builtins__", то под этим ключом будет автоматически добавлен модуль builtins.

И финальный аккорд – выполнение: exec(compiled, runtime)

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

• логированием и обработкой ошибок;

• возможностью импорта других скриптов.

С логированием и ошибками всё тривиально, однако для импорта добавлю пару замечаний.

def script_exec(script, rtl: AbstractRTL):
    """Кусочек из реального проекта. Выполняет пользовательский код,
    использующий сервисы ядра"""
    wd_old = os.getcwd()
    wd = os.path.dirname(script.name) or wd_old
    if wd != wd_old:
        os.chdir(wd)
    sys.path.insert(0, wd)
    getLogger(__name__).info(f"Трансляция скрипта {script.name} начата")
    try:
        body = script.read()
        compiled = compile(body, script.name, "exec", dont_inherit=True)

        global_dict = {
            k: getattr(rtl, k)
            for k in (set(AbstractRTL.__dict__) | set(rtl.__class__.__dict__) | set(rtl.__dict__))
            if not k.startswith("_")
        }
        global_dict.update(__file__=script.name, __name__=os.path.splitext(os.path.basename(script.name))[0])
        exec(compiled, global_dict)
        global_dict["end"]()
    except Exception:
        getLogger(__name__).exception(f"Трансляция скрипта {script.name} провалилась")
        raise
    else:
        getLogger(__name__).info(f"Трансляция скрипта {script.name} завершена успешно")
    finally:
        sys.path.pop(0)
        os.chdir(wd_old)
    return

Импорт в скриптах

Для скриптов-файлов нужно добавить каталог скриптов в список «путей импорта» sys.path и сменить текущий каталог.

Для скриптов, загружаемых из БД, сети или генератора случайных чисел придется менять механизмы импорта. Работа с этими механизмами – отдельное захватывающее приключение, поэтому интересующиеся могут заглянуть в пакет importlib стандартной библиотеки.

Безопасность

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

Заключение

С помощью показанной технологии вы можете не только значительно упростить и ускорить написание скриптов для работы с вашим приложением, но и усложнить жизнь пользователей: функционал появляется в скриптах «магическим», невидимым пользователям образом, удивляя и пугая их. Для более комфортной работы со скриптами не забывайте документировать доступные возможности. Например, используйте привычную для Python связку dir + help + docstring: пользователи обязательно скажут за это спасибо.

На этом всё. Желаю всем поменьше багов и побольше довольных пользователей.