Я решил начать с чего попроще – runtime компиляции кода. Мы не будем писать JIT-компилятор в обычном понимании, а реализуем небольшую оптимизацию для вполне практичной библиотеки.

Контекст задачи

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

@accepts(float, float)
def float_div(a, b):
    return a / b

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

Какой эффект мы ожидаем от такого декоратора? Давайте сразу на коленке добавим документацию и тесты, сразу и прояснится:

@accepts(float, float)
def float_div(a, b):
    """
    A function that divides floats.
    Any other types of arguments will throw an exception

        >>> float_div(1.0, 2.0)
        0.5
        >>> float_div(1, 1.0)
        Traceback (most recent call last):
        ...
        TypeError: Expected <type 'float'> for argument #1 got <type 'int'>
    """
    return a / b

if __name__ == '__main__':
    import doctest
    doctest.run_docstring_examples(float_div, globals())

Теперь должно стать очевидно, как реализовывать декоратор:

class accepts_wrap(object):
    def __init__(self, func, argtypes):
        self.func = func
        self.__doc__ = func.__doc__
        self.argtypes = argtypes

    def __call__(self, *args):
        for i, (arg, cls) in enumerate(zip(args, self.argtypes)):
            if not isinstance(arg, cls):
                raise TypeError("Expected %r for argument #%d got %r" % (cls, i+1, type(arg)))
        return self.func(*args)

def accepts(*argtypes):
    return lambda func: accepts_wrap(func, argtypes)

Постановка задачи

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

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

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

Модель исполнения

Поскольку в данном случае нас волнует только CPython и его байт-код, то кратко рассмотрим как он работает. При первой загрузке модуля его исходники разбираются в AST (Abstract Syntax Tree) по которому генерируется байт-код (который также кэшируется в .pyc файле). Байт-код python предназначен для исполнения несложной умеренно сложной стековой виртуальной машиной. Реализация внутреннего цикла CPython находится в файле ceval.c и ознакомиться с ним хотя бы поверхностно следует всякому интересующемуся тем, как Python работает внутри. Если вы собираетесь писать компиляцию на лету как в этой статье, то такое знакомство, хотя и не обязательно, но придется очень кстати.

Инструментарий

Python предоставляет доступ к разным этапам процесса загрузки и генерации байт-кода начиная с разбития на лексемы и построения синтаксических деревьев и заканчивая созданием из этих структур code-objects и собственно функций, классов и модулей, которые можно использовать непосредственно. Есть также возможность загружать и сохранять байткод самостоятельно, т.к. формат .pyc-файлов это знакомый всем marshal. Еще очень полезен в разработке декомпилятор байт-кода, позволяющий посмотреть какие коды получаются из существующих исходников.

В зависимости от стоящих задач можно подойти к runtime-компиляции по-разному. Ведь если для AST / compileast можно ожидать поддержки в разных реализациях интерпретатора, то для собственно байт-кода этого сказать нельзя. Так что, возможно, для многих лучшим выбором окажется работа на другом уровне, однако в этой статье мы будем генерировать байт-код непосредственно. Для этого мы воспользуемся библиотекой BytecodeAssembler.

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

>>> def foo(x, y):
...     return x + y
...
>>> from dis import dis
>>> dis(foo)
  2           0 LOAD_FAST                0 (x)
              3 LOAD_FAST                1 (y)
              6 BINARY_ADD
              7 RETURN_VALUE

А вот как можно породить такой же такой код:

from peak.util.assembler import *
c = Code()
c.LOAD_FAST('x')
c.LOAD_FAST('y')
c.BINARY_ADD()
c.RETURN_VALUE()
c.co_argcount = 2
c.co_varnames = ['x', 'y']
foo_code = c.code()

Новая реализация

Дизассемблировав внутренний цикл нашей первой реализации accepts_wrap, получим кальку, по которой можно записать новый вариант:

from peak.util.assembler import *
import new
import inspect

class accepts_wrap(object):
    def __init__(self, func, argtypes):
        self.func = func
        self.__doc__ = func.__doc__
        self.argtypes = argtypes
        self.compile()

    def compile(self):
        argnames = inspect.getargspec(self.func)[0]
        c = Code.from_function(self.func)
        c.LOAD_CONST(self.func)
        for i, cls in enumerate(self.argtypes):
            c.LOAD_FAST(argnames[i])
            c.LOAD_CONST(isinstance) # if not isinstance(arg, cls):
            c.LOAD_FAST(argnames[i])
            c.LOAD_CONST(cls)
            c.CALL_FUNCTION(2)

            skip = c.JUMP_IF_TRUE()
            c.LOAD_CONST(TypeError) # raise TypeError
            c.LOAD_CONST("Expected %r for argument #%d got %%r" % (cls, i+1))
            c.LOAD_CONST(type)
            c.LOAD_FAST(argnames[i])
            c.CALL_FUNCTION(1)
            c.BINARY_MODULO()
            c.CALL_FUNCTION(1)
            c.RAISE_VARARGS(1)

            skip()
            c.POP_TOP()
        c.CALL_FUNCTION(len(argnames))
        c.RETURN_VALUE()
        self.wrapped_func = new.function(c.code(), {})

    def __call__(self, *args):
        return self.wrapped_func(*args)

Не будем вдаваться в подробности лишь отметив, что многие операции были заменены на более дешевые. Например, isinstance загружается через LOAD_CONST а не LOAD_GLOBAL как в первом варианте. Также исчезла итерация по списку ожидаемых классов – при генерации байт-кода цикл разворачивается.

Для того чтобы понять, как всё работает, нужно иметь четкую ментальную модель стековой машины, потому что иначе загвоздки будут возникать на каждом шагу. Например, почему мы в первую очередь делаем c.LOAD_CONST(self.func)?

После вызова isinstance на вершине стека оказывается булевое значение, по которому мы проверяем валидность аргумента. В байт-коде ветвление, естественно, реализуется через JUMP. В BytecodeAssembler для прыжков на еще не объявленные лейблы есть удобное соглашение (см. в коде: skip = … создает отложенный лейбл, а skip() привязывает его к месту в коде).

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

c.LOAD_CONST(TypeError)
c.LOAD_CONST("Expected %r for argument #%d got %%r" % (cls, i+1))
c(Call(Const(type), [Local(argnames[i])]))
c.BINARY_MODULO()
c.CALL_FUNCTION(1)
c.RAISE_VARARGS(1)

Еще одна итерация и:

error_msg = Suite([ Const("Expected %r for argument #%d got %%r" % (cls, i+1)),
                    Call(Const(type), [Local(argnames[i])]),
                    Code.BINARY_MODULO])
c.LOAD_CONST(TypeError)
c(error_msg)
c.CALL_FUNCTION(1)
c.RAISE_VARARGS(1)

И еще немного:

error_msg = Suite([ Const("Expected %r for argument #%d got %%r" % (cls, i+1)),
                    Call(Const(type), [Local(argnames[i])]),
                    Code.BINARY_MODULO])
c(Call(Const(TypeError), [error_msg]))
c.RAISE_VARARGS(1)

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

        for i, cls in enumerate(self.argtypes):
            arg = Local(argnames[i])
            c(arg)
            c(Call(Const(isinstance), [arg, Const(cls)]))
            skip = c.JUMP_IF_TRUE()
            error_msg = Suite([ Const("Expected %r for argument #%d got %%r" % (cls, i+1)),
                                Call(Const(type), [arg]),
                                Code.BINARY_MODULO])
            c(Call(Const(TypeError), [error_msg]))
            c.RAISE_VARARGS(1)
            skip()
            c.POP_TOP()

Расширяемость

Далее, чтобы добиться расширяемости, реализуем тело цикла как новую конструкцию.

Для реализации process_arg есть вспомогательные средства, с ними он будет выглядеть следующим образом:

@nodetype()
def process_arg(i, argname, spec, code=None):
    if code is None:
        return i, argname, spec
    else:
        arg = Local(argname)
        code(Call(Const(isinstance), [arg, Const(spec)]))
        skip = code.JUMP_IF_TRUE()
        error_msg = Suite([ Const("Expected %r for argument #%d got %%r" % (spec, i+1)),
                            Call(Const(type), [arg]),
                            Code.BINARY_MODULO])
        code(Call(Const(TypeError), [error_msg]))
        code.RAISE_VARARGS(1)
        skip()
        code.POP_TOP()
        code(arg)

Это в свою очередь позволяет нам сократить реализацию compile:

    def compile(self):
        argnames = inspect.getargspec(self.func)[0]
        c = Code.from_function(self.func)
        code_args = [process_arg(i, argnames[i], cls) for i, cls in enumerate(self.argtypes)]
        c.return_(Call(Const(self.func), code_args))
        self.wrapped_func = new.function(c.code(), {})

На самом деле можно сократить весь класс accepts_wrap, вот что от него осталось:

def accepts(*argtypes):
    def decorate(func):
        argnames = inspect.getargspec(func)[0]
        code_args = [process_arg(i, argnames[i], cls) for i, cls in enumerate(argtypes)]
        c = Code.from_function(func)
        c.return_(Call(Const(func), code_args))
        wrapped = new.function(c.code(), {})
        return rewrap(func, wrapped) # preserve name / __doc__
    return decorate

Вот весь наш код на данный момент, совсем немного. Благодаря тому, что обработка каждого аргумента вынесена в process_arg, несложно переопределять её для особых случаев. Например, на данный момент мы предполагаем что аргументами декоратора будут классы, можно же предположить, что ими могут также быть некие другие объекты, описывающие требования к аргументу. При условии, что мы умеем генерировать для этих проверок оптимальный код (эту задачу можно делегировать самим декларациям) мы получим свободно расширяемый предобработчкик аргументов. Естественно, в реальном проекте начинать надо с более традиционной реализации, но данная статья, я надеюсь, в какой-то мере демонстрирует каким образом возможно усиливать некоторые библиотеки частичной компиляцией на лету.

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

Интересное про байт-код и интерпретатор CPython

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

• Для получения атрибута нет специальной команды, компилятор генерирует последовательность команд LOAD_CONST(getattr), LOAD_XXX(obj), LOAD_CONST(attrname), CALL_FUNCTION(2)
• Локальные переменные во много раз быстрее глобальных. Поиск глобальной переменной это доступ к словарю, а для локальной переменной это доступ к ячейке стека по заранее известному индексу.
• Переменные общие для замыканий или объявленные уровнем выше реализованы через специальные структуры данных, для доступа к ним существуют отдельные команды.
• На уровне интерпретатора реализовано предсказание последовательностей команд для ускорения наиболее часто встречающихся цепочек.

Если есть какие-то вопросы, связанные с этой темой, спрашивайте в комментариях, попробую ответить.

Постановка задачи

Допустим мы пишем веб-приложение, использующее какую-то JS-библиотеку, в нашем примере YUI. Давайте попробуем инкапсулировать логику её подключения к странице. Для таких задач есть целый ряд «решений» вроде ToscaWidgets, но толку от них ноль, как это и принято среди всего имеющего в названии слово “widget”.

Фактически YUI может быть размещена на серверах Yahoo, на нашем сервере где-то рядом с приложением или где-то еще, мы будем поддерживать все эти варианты. Также удобно иметь возможность раздавать библиотеку прямо из дистрибутива (yui_x.x.x.zip) не распаковывая.

Приложение будет запрашивать у компоненты HTML код для подключения интересующих её модулей. У модулей есть debug и min версии, поэтому компонента должна учитывать и это. Мы будем местами срезать углы, например, у некоторых компонент в некоторых версиях есть дополнительный суффикс ‘beta’, но мы это будем игнорировать. Учесть это несложно, но в рамках статьи не оправдано. Точно также мы не будем выстраивать правильный порядок включения скриптов, зависимости, подключение CSS файлов их минификацию и прочие детали. В настоящей компоненте это всё следует реализовать – времени это займет минимум, а использовать её станет еще удобней и приятней. И всё же некоторые несущественные детали мы будем учитывать в нашей реализации для того чтобы было видно что это не требует никакой магии – всё отлично решается «в лоб».

Подготовительные шаги

Для начала давайте напишем небольшое приложение для тестирования компоненты:

class App(object):
    def __init__(self, yui):
        self.yui = yui

    @webob_wrap
    def __call__(self, req):
        names = [name for name in req.path_info.split('/') if name]
        links = self.yui.js_links(names)
        return Response(links, content_type='text/plain')

if __name__ == '__main__':
    from paste.httpserver import serve
    yui = YuiYahooHosted(version='2.5.2', debug=True)
    root = App(yui)
    serve(root)

Конечно, для целей тестирования разумно вызывать непосредственно компоненту, но этот пример заодно показывает как она используется в реальном приложении. Для компоновки не требуется никаких трюков или специальных библиотек. На самом деле интересно, кому впервые пришла идея, что так писать недостаточно хорошо, и сколько человеко-часов было угроблено на хитросплетения под девизом «не повторяй себя»?

Итак, если мы захотим посмотреть в браузере как выглядит блок ссылок на скрипты history, animation и json мы откроем http://localhost:8080/history/animation/json итп.

В результате мы увидим результат подобный следующему:

<script type="text/javascript" src="http://yui.yahooapis.com/2.5.2/build/history/history-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.2/build/animation/animation-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.5.2/build/json/json-min.js"></script>

В конечном счете эта строка результат вызова

yui.js_links(['history', 'animation', 'json'])

Вариант для Yahoo CDN

Начнем с реализации YuiYahooHosted:

class YuiYahooHosted(object):
    prefix_template = 'http://yui.yahooapis.com/%s/build/'
    prefix_cn_template = 'http://cn.yui.yahooapis.com/%s/build/'
    js_link_template = '<script type="text/javascript" src="%(prefix)s%(name)s/%(name)s%(suffix)s.js"></script>'

    def __init__(self, version, debug=False, minified=False, china=False):
        if debug and minified:
            raise ValueError("Scripts can't be both minified and debuggable")

        self.version = version
        self.debug = debug

        self.minified = minified
        self.china = china

        if china:
            self.prefix = self.prefix_cn_template % version
        else:
            self.prefix = self.prefix_template % version

        if debug:
            self.suffix = '-debug'
        elif minified:
            self.suffix = '-min'
        else:
            self.suffix = ''

    def js_links(self, names):
        links = []
        subst = {'prefix': self.prefix, 'suffix': self.suffix}
        for name in names:
            subst['name'] = name
            links.append(self.js_link_template % subst)
        return '\n'.join(links)

Трудно придумать что-то более очевидное. Понять что делает компонента очень просто, и это здорово даже если никто кроме вас никогда не будет читать ваш код. Но даже для простого кода документация не помешает.

    """
    Create a component that generates links to YUI scripts hosted by Yahoo!.

        Constructor Arguments:

            ``version``     YUI version (as of June 2008 the current version is 2.5.2)
            ``debug``       (False by default) Use debug versions of the scripts
            ``minified``    (False by default) Use minified versions of the scripts
            ``china``       (False by default) if True, generated links will point to China-based CDN

    ``js_links(names)``

        Takes a list of script names (for ex. ['cookie', 'history']) and returns HTML to include in your page.

    """

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

Рефакторинг и выделение общей функциональности

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

class YuiLinkGen(object):
    """
    Create a component that generates links to YUI scripts.

        Constructor arguments:

            ``prefix``      Specifies prefix for the generated URIs (location of the YUI files)
            ``debug``       (False by default) Use debug versions of the scripts
            ``minify``      (False by default) Use minified versions of the scripts (debug flag takes precedence)
    """

    js_link_template = '<script type="text/javascript" src="%(prefix)s/%(name)s/%(name)s%(suffix)s.js"></script>'

    def __init__(self, prefix, debug=False, minify=False):
        self.debug = debug
        self.minify = minify
        self.prefix = prefix

        if debug:
            self.suffix = '-debug'
        elif minify:
            self.suffix = '-min'
        else:
            self.suffix = ''

    def js_links(self, names):
        """
        Takes a list of script names (for ex. ['cookie', 'history']) and returns HTML to include in your page.
        """
        links = []
        subst = {'prefix': self.prefix, 'suffix': self.suffix}
        for name in names:
            subst['name'] = name
            links.append(self.js_link_template % subst)
        return '\n'.join(links)

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

class YuiYahoo(YuiLinkGen):
    """
    Create a component that generates links to YUI scripts hosted by Yahoo!.

        Contructor arguments:

            ``version``     YUI version (as of June 2008 the current version is 2.5.2)
            ``debug``       same meaning as in YuiLinkGen
            ``minify``      same, but True by default
            ``china``       (False by default) if True, generated links will point to China-based CDN

    """
    prefix_template = 'http://yui.yahooapis.com/%s/build'
    prefix_cn_template = 'http://cn.yui.yahooapis.com/%s/build'

    def __init__(self, version, debug=False, minify=True, china=False):
        if china:
            prefix = self.prefix_cn_template % version
        else:
            prefix = self.prefix_template % version
        self.version = version
        self.china = china
        super(YuiYahoo, self).__init__(prefix=prefix, debug=debug, minify=minify)

Что ж, пока что всё было просто, как насчет того чтобы совместить генерацию ссылок и собственно хостинг скриптов?

Размещение на собственном сервере

Поскольку задачи предоставления папки или zip-архива уже решены в Paste, то реализация выйдет на удивление короткой. Соотношение кода к документации, как положено, приближается к 1:1.

class YuiSelfHosted(YuiLinkGen):
    """
    This class implements a component that generates links to YUI scripts hosted by ourselves
    and can create the app used to serve the files from directory or distro zipfile.

        Constructors:

            ``from_directory()``

                ``prefix``      same meaning as in YuiLinkGen constructor
                ``dirpath``     filesystem path to 'build' directory from YUI distro
                ``debug``       same as in YuiLinkGen
                ``minify``      asks to minify the served files. No -min suffixes are
                                generated and debug versions can be minified too.
                ``gzip``        (True by default) asks to gzip responses if possible.

            ``from_distro_zipfile()``

                Same as ``from_directory()``, but instead of ``dirpath`` argument it takes
                ``filename`` which would be the .zip file containing the YUI distribution to serve
                (as downloaded from YUI website).

        Attributes:

            ``yuiapp``  WSGI app to be mounted at ``prefix``

    """

    def __init__(self, prefix, yuiapp, **kw):
        super(YuiSelfHosted, self).__init__(prefix, **kw)
        self.yuiapp = yuiapp

    @classmethod
    def from_distro_zipfile(cls, prefix, filename, **kw):
        from paste.fileapp import ArchiveStore
        app = ArchiveStore(filename)
        @webob_wrap
        def restrict_app(req):
            req.path_info = '/yui/build' + req.path_info
            return req.get_response(app)
        return cls.from_app(prefix, restrict_app, **kw)

   @classmethod
   def from_directory(cls, prefix, dirpath, **kw):
       from paste.urlparser import StaticURLParser
       app = StaticURLParser(dirpath)
       return cls.from_app(prefix, app, **kw)

    @classmethod
    def from_app(cls, prefix, yuiapp, debug=False, minify=False, gzip=True):
        return cls(prefix, cls.wrap_app(yuiapp, minify=minify, gzip=gzip), debug=debug)

    @classmethod
    def wrap_app(cls, app, minify, gzip):
        if minify:
            app = jsminify_middleware(app)
        if gzip:
            from paste.gzipper import middleware as gzip_middleware
            app = gzip_middleware(app)
        return app

Опять, не прибегая ни к каким трюкам, получился качественный код. В этой реализации мы используем написанную в предыдущей статье мидлварь и вместо того чтобы для минификации добавлять суффикс –min к имени файла, мы минифицируем его самостоятельно. Это позволяет минифицировать также отладочные версии скриптов (полезно разве что для отладки скриптов удаленно размещенного приложения, что случается не часто), но главное наша минификация отрезает заголовки с копирайтом которые сохранены в файлах из дистрибутива – каждый байт на счету! А если серьезно, то собственная минификация пригодится на следующем этапе.

Мы также оборачиваем приложения в gzipper, но и это можно отключить передав конструктору gzip=False.

Обратите внимание на restrict_app из from_distro_zipfile, таким образом мы ограничиваем доступ папкой build из дистрибутива и облегчаем себе одну предстоящую задачу (о которой позже).

Собственно в интеграции генератора ссылок и самого WSGI приложения со скриптами нет ничего мудреного, у генератора есть атрибут yuiapp с приложением, которое скрипт конфигурации должен сделать доступным по префиксу указанному в конструкторе.

Использование

Поскольку мы отказались от использования специальных систем конфигурации, получившийся код готов к употреблению. App – приложение использующее значение аргумента своего конструктора как генератор ссылок на скрипты. Оно делает вызовы вроде self.yui_linkgen.js_links([…]) и потому полностью совместимо со всеми нашими реализациями, никакие их внутренние отличия его не касаются.

Уже размещенные скрипты

yui = YuiLinkGen('http://static.website.com/scripts/yui', minify=True)
application = App(yui)

На серверах Yahoo

yui = YuiYahoo(version='2.5.2')
application = App(yui)

Самостоятельно

yui = YuiSelfHosted.from_directory('/_yui', '/home/web/checkouts/yui/build', minify=True)

или

yui = YuiSelfHosted.from_distro_zipfile('/_yui', 'yui_2.5.1.zip')

root = URLMap()
root['/_yui'] = yui.yuiapp
root['/'] = App(yui)

application = root

или в ходе тестирования:

serve(root)

Если мы знаем домен по которому будет размещен root, то стоит добавить его к первому аргументу.

Обратите внимание, что однажды создав экземпляр YuiLinkGen, мы можем использовать его многократно, если у нас есть несколько приложений способных использовать такую компоненту разумно передавать им одну и ту же копию. Реализовать это не используя в конфигурации Python было бы затруднительно, к тому же не ясно: чего ради?

Что-то новенькое

Если в прошлой статье мы сумели сделать минификацию более удобной, то возможно нам удастся упростить склейку скриптов? Чем больше запросов браузер шлет к серверу тем обычно больше задержка при загрузке страницы, поэтому при переходе в продакшн толково сделанные (читай «не встречающиеся в природе») сайты склеивают свои скрипты в один файл, все CSS-файлы в другой и используют их в таком виде. Это уменьшает количество запросов к серверу, что в свою очередь уменьшает нагрузку на него, делает проверку на изменения гораздо более быстрой (важно при обновлении страницы пользователем), gzip на склеенных скриптах эффективнее чем на раздельных итд итп. Иногда для разных страниц нужно использовать разное подмножество скриптов и тогда у подхода описанного ниже обнаружатся и недостатки, но это особый случай и решать его также нужно отдельно. Для большинства случаев мы получим заметный выигрыш используя следующую стратегию.

Для начала мы сделаем middleware способную склеивать скрипты на лету. Мы хотим чтобы путь вида «/history/history;/json/json.js» был командой к тому чтобы вернуть склеенные /history/history.js и /json/json.js. Мы реализуем это как middleware а не новое приложение склеивающее файлы с диска для того чтобы воспользоваться, среди прочего, предоставлением файлов из архива. К этому, безусловно, нужно добавить кеширование, но в этой статье мы это опустим.

@webob_middleware
def jsjoin_middleware(req, app):
    if req.path_info.endswith('.js') and req.method in ['GET', 'HEAD']:# and not req.query_string
        parts = req.path_info[:-3].split(';')
        if len(parts) > 1:
            subresponses = []
            for part in parts:
                subreq = req.copy()
                subreq.remove_conditional_headers()
                subreq.path_info = part + '.js'
                subres = subreq.get_response(app)
                if subres.content_type not in js_mimetypes or subres.status_int != 200:
                    return HTTPNotFound(comment="%s not found" % subreq.url)
                subresponses.append(subres)
            r = Response(content_type='text/javascript', charset='UTF-8')
            bodies = []
            for subr in subresponses:
                if subr.charset:
                    bodies.append(subr.unicode_body or '')
                else:
                    bodies.append(unicode(subr.body or ''))
            r.md5_etag()
            r.last_modified = max([subr.last_modified for subr in subresponses if subr.last_modified] or [None])
            r.conditional_response = True
            return r
    return req.get_response(app)

Для наших нужд можно было бы опустить работу с юникодом и генерацию правильного last-modified, но я привожу эти фрагменты, чтобы не создать ложного впечатления о том насколько всё просто. Всё просто, но всё же нужно быть внимательным к деталям. По уму также можно не генерировать тело ответа целиком, а склеивать его по мере надобности в app_iter. Главным преимуществом этого была бы экономия в случае ответов 304 Not Modified, но, поскольку мы собираемся кешировать ответы, то генерация полного тела ответа – правильный подход.

Генерация ссылок на склеенные скрипты

Теперь нужно научить нашу реализацию генерировать ссылки на такие склеенные скрипты.

class YuiMerge(YuiLinkGen):
    js_link_template = '<script type="text/javascript" src="%s/%s.js"></script>'
    js_part_template = '%(name)s/%(name)s%(suffix)s'

    def js_links(self, names):
        """
        Same as YuiLinkGen.js_links but generates a link that will fetch all scripts as one file
        """
        parts = []
        subst = {'suffix': self.suffix}
        for name in names:
            subst['name'] = name
            parts.append(self.js_part_template % subst)
        return self.js_link_template % (self.prefix, ';/'.join(parts))

Это прямой наследник YuiLinkGen и может использоваться в тех же случаях. Например вместо блока ссылок вначале статьи он вернет

<script type="text/javascript" src="/yui/history/history;/animation/animation;/json/json.js"></script>

Может ли случиться что нам нужно генерировать такие ссылки не создавая соответствующего приложения для склейки? Это возможно, если такое приложение размещено на другом сервере или процессе. Для более частого случая, когда нам нужны обе части, пригодится следующий класс:

class YuiHostedMerge(YuiMerge, YuiSelfHosted):
    @classmethod
    def wrap_app(cls, app, *args, **kw):
        app = jsjoin_middleware(app)
        return super(YuiHostedMerge, cls).wrap_app(app, *args, **kw)

Обратите внимание на граф наследования, вернитесь к коду и прочитайте его весь еще раз. Заметьте, что YuiJoinHostedLinkGen унаследовал конструкторы from_directory и from_distro_zipfile с соответствующей им семантикой, но добавил поддержку склеивания. Я хочу еще раз подчеркнуть, что если вы пишете код в таком стиле, то вы используете или учитесь использовать те же навыки и архитектурные решения что и при разработке в любой другой области. Если вы умеете применять ООП к месту, если вы видите смысл в документировании кода, если имеете навык деления функциональности на компоненты, то это пригодится в любой области программирования. Нельзя применять особые критерии к веб-разработке: хранение запроса в глобальной переменной – в любом случае извращение, много кода ни о чем – плохой знак, если нет ясных стыков, на которых нужно писать документацию – плохи дела и т.д. Сделать хорошо – можно, но для этого нужно иметь свободу делать как угодно, и для этого WSGI бесценен.

PS

В конце прошлой статьи я предлагал написать реализацию декоратора webob_middleware (мы использовали его в этой статье) который превращал бы функцию с сигнатурой (Request, WSGI) → WSGI в конструктор соответствующей мидлвари. Сегодня было написано немало приличного кода, поэтому в качестве передышки предлагаю решение в одну строчку (вообще так писать не надо):

webob_middleware = lambda mw: lambda app: webob_wrap(lambda req: mw(req, app))

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

Middleware

Стандарт какого-то интерфейса создает пространство для особого рода компонент – middleware. Это слово часто употребляют в смысле «адаптер» (совместно с которыми мидлварь часто используется), хотя это не совсем верно. Я стараюсь использовать его только в узком смысле – компонента предоставляющая и потребляющая один и тот же интерфейс. Например, load-balancer это middleware, кеширующая прослойка – тоже, а вот преобразователь XML-RPC ↔ SOAP уже под вопросом. В нашем случае middleware будет потреблять и предоставлять, конечно же, WSGI. Таким образом у нас есть возможность придать новые свойства любому существующему WSGI-приложению. Ряд уже готовых mw уже был упомянут в первой статье серии, и их еще огромное множество, но мы рассмотрим, как написать такую компоненту с нуля.

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

JSMin

Начнем c примера попроще. Всем кто использовал в приложениях JavaScript известно, что, для ускорения загрузки, скрипты можно «минифицировать». Для этого есть разные инструменты, так что само по себе это не проблема. Неудобство в том, что иметь отдельные укороченные скрипты очень неудобно – чтобы их содержимое не устаревало нужно добавить специальный шаг в процесс деплоймента, да и может выйти, что какой-то из скриптов был забыт и прочие подобные неприятности. Для большинства случаев можно обойтись меньшей кровью написав мидлварь которая паковала бы скрипты на лету. На машине разработчика использовать её не стоит т.к. может понадобиться полистать используемые скрипты в браузере, но если вы усвоили идеи из статьи про деплоймент, то ничего сложного в этом не окажется.

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

Решением должна быть такая функция jsminify_middleware чтобы приложение, получающееся в следующем коде, возвращало все JS-скрипты минифицированными. Тут предполагается что ‘yui’ это папка с дистрибутивом YUI (как вполне вероятный вариант применения).

from paste.urlparser import StaticURLParser
yui_app = StaticURLParser('yui')
yui_app = jsminify_middleware(yui_app)

Решение

Решение может быть например таким:

js_mimetypes = frozenset(['text/javascript', 'application/x-javascript'])

def jsminify_middleware(app):
    @webob_wrap
    def middleware_app(req):
        r = req.get_response(app)
        if r.content_type in js_mimetypes and r.body:
            r.body = jsmin(r.body)
        return r
    return middleware_app

Тут нет ничего нового. Мы просто создали замыкание (middleware_app), которое является WSGI-приложением, которое, вместо того чтобы генерировать ответ самостоятельно, поручает эту задачу обернутому приложению. Затем полученный от него ответ мы проверяем по типу содержимого и если там JS, то обрабатываем тело ответа jsmin.

Обращу внимание на ряд вещей:

• Если нижележащее приложение поддерживает If-None-Match или If-Modified-Since эта поддержка сохраняется.
• Мы проверяем наличие тела ответа, т.к. ответ может иметь Content-Type, но быть пустым, например 304 Not Modified. У таких ответов .body is None.
• Мы проверяем наличие тела ответа в последнюю очередь, т.к. доступ к атрибуту .body линеаризует ответ, а в случае, когда мы не собираемся дополнительно его обрабатывать, это привело бы к бессмысленной потере эффективности и трате памяти.
• Мидлварь применима к любому приложению и потому может также минифицировать скрипты из архива или даже сгенерированные динамически. Мы также можем обернуть ей приложение написанное с использованием фреймворков – до внутренностей нам нет никакого дела.

Ошибки в реализации

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

Ошибки такие: мы не учитываем, что ответ может быть закодированным (content-encoding: gzip) или частичным (range).

Content-Encoding

Чтобы исправить первое, достаточно добавить r.decode_content(), впрочем, поскольку скрипты неплохо бы еще и сжать при передаче, давайте добавим и это.

        if r.content_type in js_mimetypes and r.body:
            r.decode_content()
            r.body = jsmin(r.body)
            if 'gzip' in req.accept_encoding:
                r.encode_content()

Как вариант последние две строки можно записать так:

r.encode_content(req.accept_encoding.best_match(['gzip', 'identity'], 'identity'))

Эти варианты не идентичны. В том случае если user agent прислал заголовок Accept-Encoding: gzip;q=0.5,identity;q=1 первый вариант запакует ответ, а второй прислушается к пожеланиям агента и запаковывать не станет. Конечно, если мы очень дорожим своим каналом, то у нас тоже может быть предпочтение по-поводу того в каком виде отдавать данные. В таком случае мы можем записать всё ту же строку следующим образом:

r.encode_content(req.accept_encoding.best_match([('gzip', 1), ('identity', 0.2)], 'identity'))

Таким образом мы указываем что отдавать скрипты в сжатом виде для нас предпочтительнее в пять раз. В таком случае на тот же запрос данные всё же будут запакованы, т.к. 1*0.5 > 0.2*1. Но мы всё же оставляем клиенту шанс указать что незапакованные данные предпочтительнее если в запросе будет достаточно низкий q для gzip.

Безусловно, в данном случае, это всё изыски имеющие мало общего с реально стоящими задачами, но случаи бывают разные и возможность работать с HTTP-стандартом как положено порой оказывается очень ценной.

Range

Исправить ошибку с частичным ответом (Range) можно несколькими путями. Вполне приемлемый вариант оставить всё как есть – вряд ли когда либо случится так, что скрипт будут скачивать по частям.

Можно добавить условие “and not r.range” чтобы не обрабатывать такие ответы дополнительно. В таком случае разумно при упаковке изменять Etag ответа, чтобы при корректном (с If-Range) запросе на частичное содержимое нижележащее приложение замечало бы разницу с ожидаемым Etag и отдавало цельный ответ. Это позволит избежать маловероятной ситуации когда клиент начал скачивать скрипт в минифицированом виде, но из-за обрыва соединения вынужден был попробовать снова и послал запрос на недостающую часть. В таком случае помимо Range он должен бы указать заголовок If-Range со значением Etag из первого ответа. Если Etag пакованного и оригинального ответа не отличаются то в результате клиент получит нерабочего «мутанта» склеенного из несовместимых частей. Изменение Etag спасает ситуацию, но к сожалению такой подход не поможет если в If-Range будет указан не Etag а Last-Modified оригинального ответа, что тоже допустимо по стандарту.

Поэтому самый надежный способ – удалить Range и If-Range из запроса до того как передавать управление нижележащему приложению (req.range = None). Но из-за этого перестанут работать все запросы на частичное содержимое и потому такую мидлварь нужно будет применять осторожнее, чтобы ненароком не обернуть ей, например, какой-то большой файл для скачки.

Nuke the entire site from orbit. It’s the only way to be sure.

Для таких случаев также предусмотрен метод Request.remove_conditional_headers по умолчанию удаляющий из запроса не только Range но и Accept-Encoding (исправляя заодно нашу первую ошибку), If-None-Match и If-Modified-Since гарантируя таким образом что ответ будет полным и без Content-Encoding. Для нашей задачи это перебор, но знать о его существовании стоит.

Домашнее задание

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

• Минификация и gzip архивация занимают время, развейте имеющийся код так, чтобы обработанные ответы кешировались, в том числе пакованые gzip. Укажите какие сделаны предположения и для оборачивания каких приложений это не подойдет. Тут есть целый ряд альтернативных подходов и правильных ответов тоже множество.
• Создайте декоратор для удобства написания простых middleware, предполагаемое использование такое:

  @webob_middleware
  def jsminify_middleware(req, app):
      r = req.get_response(app)
      #...
      return r

Ответы можно давать в виде ссылок на ваш вариант на pastebin.

Комментарий Ивана Салагаева: Тут я хочу сказать, что от таких эффектов все равно нельзя защититься. Большинство людей любят не думать, что от чего зависит, а сразу ищут однозначных ответов. И уж тем более, если их пишет человек с авторитетом (который у меня, уж как получилось, есть). Моя статья, хоть и эмоционально написана, отвечает, как ты сам заметил, не конкретно на твой обзор WebOb, а использует его как повод для развития моей собственной точки зрения, которую я постарался обрисовать в начале. (WebOb важная часть, но статьи не только про него – примечание СЩ).

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

Начать стоит, пожалуй, с того, что я не агитирую никого бросать их любимый фреймворк, не призываю писать свой собственный, я вообще ничего не предлагаю и не требую. Статьи описывают библиотеки, которыми пользуюсь я сам и приводят примеры как выглядит в результате код, не более того. Статьи не предназначены для новичков, для того чтобы эффективно писать код в том стиле, как делаю это я, необходимо хорошо понимать как работают все задействованные уровни включая HTTP протокол, сам стандарт WSGI, диспатчинг, шаблоны, используемый ORM и сама база данных, объяснить всё это я могу лишь отчасти. Пожалуй нелишним будет опыт разработки на нескольких существующих web-фреймворках. Я начал программировать для веб на Python шесть лет назад, и хотя были перерывы, имею солидный опыт использования самых разных фреймворков, поэтому не надо думать, что я пишу код таким способом из-за того что страшусь использовать существующие.

Велосипеды

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

Для того чтобы внести ясность попробую объяснить различие между фреймворком и библиотеками. Framework в переводе с английского это буквально каркас, т.е. ваш код является вторичным по отношению к библиотечному коду. Не вы выбираете где и что использовать, а расширяете и переопределяете уже имеющуюся функциональность. Более четким критерием отличия фреймворка будет повсеместное использования инверсии контроля, будь это декларативный код или callbacks^[1].

Я исхожу из того, что этого нужно избегать насколько только возможно. Это вопрос личного предпочтения – если вам нравится писать код в колбеках, если это вам не мешает, то, вероятно, у нас совершенно разные стили программирования и мой опыт вам ни к чему. Если же вы улавливаете преимущества более свободного структурирования кода, то, возможно, программировать при помощи библиотек окажется удобней и продуктивней^[2].

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

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

Также Иван предположил, что такой подход продиктован «чистотой» WSGI, но ничто не может быть дальше от правды. Как раз поиском решений для всего и сразу страдают фреймворки. Они часто исходят из какой-то идеологии (например MVC). Очень часто пытаются спрятать сложность веб-приложения за избранными абстракциями итд итп. Благодаря же WebOb получается укротить эту сложность, оставив притом всю доступную мощь на кончиках пальцев. Что приводит нас к следующему пункту.

«… в качестве клея компонентов… WSGI! Нет, серьезно – WSGI!!!»

Объясню, почему в статьях всё крутится вокруг WSGI. Поскольку я стараюсь максимально использовать существующие библиотеки, поскольку я стараюсь не терять возможностей на разных уровнях приложения, то я привязываюсь к WSGI. Если мы хотим использовать разные библиотеки совместно мы вынуждены использовать WSGI. Посмотрите на URLMap, посмотрите на различные middleware, без предоставления и использования WSGI они были бы невозможны. Из-за того что фреймворки идут другим путем и выбирают другую, предположительно лучшую, модель представления запросов и ответов именно для них так часто приходится изобретать велосипед, ведь нужно вписаться в идеологию фреймворка. В таких случаях обычно говорят о важности интеграции родных компонент и прочую лабуду, однако правда гораздо проще – просто приходится делать заново или что-то перекручивать^[3].

Я знаю мнение PJE о том, что middleware злоупотребляют и я с ним полностью согласен. Ядро его недовольства он сформулировал так: «If your application requires that API to be present, then it’s not middleware any more!». Совершенно верно, однако есть ряд случаев когда middleware единственно верное решение, например paste.gzipper. Это те случаи когда оборачиваемые приложения не знают и не должны знать что они обернуты, к такому использованию прослоек претензий быть не может.

Не нужно думать что такие рассуждения идут вразрез с мейнстримом в веб-разработке. Дело лишь в том, что и распространенность поддержки WSGI и, скажем, выпуск WebOb произошли относительно недавно. Поэтому неизбежная инерция продолжает двигать разработку фреймворков – уже есть программисты с такими навыками, уже есть туча проектов требующих поддержки, кроме того всегда будет приток новичков для которых необходимо ограничивать сложность разработки (но ценой доступной мощности), также никуда не исчезнут желающие сделать лучше чем все предшественники. Также обратите внимание на возраст разных фреймворков, большинство уходит корнями в такую древность, что никаких WSGI, никаких вспомогательных библиотек просто не было. Более новые библиотеки зачастую были созданы с учетом ошибок и находок из фреймворков, с использованием современных средств языка и нет ничего странного что использовать их порой оказывается удобней.

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

Диспатчинг

Мне, без дураков, больше нравится писать серию if или, скажем return self.appmap.get(req.path_info_pop()). Если ваш пуризм (или менеджер проекта) требует чтобы это было сделано иначе – делайте, для этого, среди прочего, есть например Routes. Не нужно ни писать заново, ни платить цену использования фреймворка.

Вообще, многих программистов похоже пугает писать код, как только они пишут код приложения, они думают «О Боже! Почему этого не делает за меня фреймворк!?». Конечно, размышляя таким образом, получится, что диспатчинг вручную – зло, и срочно надо писать свою библиотеку или хвататься за готовую. Если же не спешить, и не побояться сделать самому решение именно имеющегося вопроса (подчеркиваю – не универсальное решение), то может оказаться, что паника была преждевременной, и кода вышло меньше, код вышел понятней, в будущем менять его проще. Так выходит у меня. Извините.

Остальное

«Что произойдет, если клиент пришлет невалидную utf-8 строку?» (см. третью статью в серии). Произойдет то что и должно произойти – клиент получит ошибку (нет, ничего не упадет, снова извините)^[4]. Какие такие «ваши данные» выжмет Django из невалидной строки я не знаю, но мне такие и не надо. Может вам нравится иначе, но это, по крайней мере, соответствует PyZen и здравому смыслу.

Кстати, если посмотреть на The Zen of Python в целом (или его русский перевод), то почти по каждому пункту веб-фреймворки идут против него, такое моё мнение. Это не аргумент против, просто наблюдение^[5].

1. ^ ИС: Кстати… Джанго, как немногие знают, очень близко подходит к этой границе: в нем очень много просто библиотечного кода, который не является каркасом. Да, Джанго, несомненно фреймворк, потому что предоставляет архитектуру обработки запроса с разбором url’ов и вызовом пользовательской view. Но это, пожалуй, и все. Шаблоны, обработка форм, ORM — это фактически внешние библиотеки, которые пользователь зовет сам, и тогда, когда ему надо. Единственное, чем тут помогает Джанго — примерами в документации.
   Тот же Pylons в этом смысле существенно глубже находится в зоне “фреймворк”.
2. ^ Мне действительно нравятся те места, где Джанго строит “собственный путь” по той простой причине, что он совпадает с тем, что сделал бы я сам. А это значит, что он экономит мне время.
   Но в целом, я полностью согласен с тем, что это вопрос личного стиля.
3. ^ А я тогда объясню, почему я так резко реагирую :-). Дело в том, что я удивительно часто встречаюсь с точкой зрения, что WSGI — это такая великая магия, и если на сайте фреймворка на первой странице написано это слово, то фреймворк автоматически считается дико гибким и мощным. Моя цель — объяснить, что WSGI — это простой протокол, который очень удобно использовать в качестве базы, но который сам по себе никакой архитектуры не строит. В WSGI нет, например, понятия каскада приложений. Его так использует тот же Paste, но это не само по себе происходит.
   И снова, это я отвечаю не на то, что ты пишешь, а разъясняю, что имел в виду я сам. (С последним полностью согласен – СЩ)
4. ^ Тут под “упадет” я имел в виду не то, что приложение остановится на сервере. Я имел в виду как раз 500 ошибку. Это, я так понимаю, просто разница в жаргоне. (Насколько я понял, просто был выбран неудачный пример для критики – СЩ)
5. ^ О, вот это точно флеймообразующий абзац :-). 9-й пункт в Дзен (”Although practicality beats purity”) дает возможность трактовать все что угодно как угодно :-). Поэтому я обычно на Дзен ссылаюсь только в шуточной манере. (А как же остальные пункты! – СЩ)

Сама задача WSGI стандарта – установить интерфейс, через который HTTP сервер будет общаться с веб-приложением, так что не приходится беспокоиться поддерживается ли нравящийся нам вариант связки или сервер. Выбор большой:

• Реализация HTTP сервера непосредственно на Python
  • wsgiref (однопотоковый)
  • paste.httpserver
  • cherrypy.wsgiserver
  • Twisted (пример использования)
  • В дополнение нередко применяются reverse proxy (Apache, lighttpd, Squid)
• CGI
• FastCGI
• SCGI
• AJP
• Apache + mod_python
• Apache + mod_wsgi

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

mod_wsgi

Как ясно из названия, это модуль Apache написанный специально для связки непосредственно с WSGI приложениями. Я думаю для многих важно, что в нем есть базовая поддержка хостинга пользовательских скриптов в shared-hosting окружениях. На самом деле одной из ведущих мотиваций при написании этого замечательного модуля было сделать хостинг веб-приложений на Python доступнее, а сами приложения в таких условиях быстрее. mod_wsgi показал себя отлично в реальных условиях, работает стабильно, быстро и безошибочно, потому можно рассчитывать, что он получит распространение среди хостеров. Также он на пути к включению в основные репозитории Debian.

Приблизительная модель работы этого модуля такова:

• Есть один или более именованных пулов python-процессов обрабатывающих запросы. Обратите внимание, что, среди прочего, благодаря этому снимаются какие-либо вопросы к поддержке параллельных вычислений в Python
• Конфигурация сервера позволяет определять политику наполнения пулов процессами (минимальное и максимальное их количество, количество потоков в каждом, таймауты и прочее)
• У каждого пула может быть свой python-path. Таким образом, можно создавать независимые окружения (при помощи virtualenv) не привязанные к версиям библиотек установленных на системе глобально или в других окружениях. Такие окружения также могут принадлежать непривилигерованым пользователям
• Есть довольно гибкий механизм для определения какой группой процессов будет обработан тот или иной запрос. На это могут влиять довольно высокоуровневые переменные вроде имени пользователя (при условии, что аутентификация была проведена самим Apache)
• Для крайне нагруженных серверов можно использовать менее гибкий, зато еще более быстрый вариант связки – встраивание интерпретатора и исполнение приложения непосредственно в процессе Apache.

Каким же именно образом в конфигурации сервера указывается WSGI приложения и их конфигурация? Пожалуй самым простым из возможных – указанием Python-скрипта по исполнению которого в его пространстве имен окажется переменная application значение которой и будет использовано как WSGI-приложение. Скрипт может иметь любое имя, но принято давать таким файлам расширение .wsgi. Как правило, такой скрипт будет импортировать все необходимые компоненты и конфигурировать их для данного размещения. Может показаться, что это какой-то недостаточно мощный или непродуманный подход, но опыт показывает, что это оптимальное решение. Для того чтобы стало понятней почему я так считаю, давайте кратко рассмотрим альтернативный подход.

PasteDeploy

PasteDeploy – это, в первую очередь, средство конфигурации и компоновки WSGI приложений, а также выбора и конфигурации связки с веб-сервером. Предназначено оно, среди прочего, для конечного пользователя / администратора не обязательно знакомого с Python, поэтому конфигурация хранится в .ini файлах. Эту конфигурацию можно запускать, мониторить и в целом использовать как UNIX-демон благодаря команде paster из PasteScript. На первый взгляд это хорошее решение, но практическое его использование раскрывает ряд недостатков.

Я не буду вдаваться в подробности его применения, так как моя цель раскритиковать такой подход, а не научить им пользоваться. Вкратце конфигурация содержит отдельные секции для каждого используемого приложения, фильтра (middleware) и сервера. Используемые приложения указываются в виде URI в специальных схемах. Наиболее используемая URI-схема egg: указывает на setuptools entry point, который является заводом (factory) по производству искомых приложений из передаваемой конфигурации. Также есть схема для использования других конфигурационных файлов (config:).

Я не буду перечислять преимущества системы, сосредоточившись на недостатках, потому что они не так очевидны без опыта использования.

• Для того чтобы сделать свое приложение доступным необходимо:
  • определить функцию или класс производящие приложения из конфигурации. Тут открываются разные детали:
    • предусмотренных переменных конфигурации всегда оказывается мало и со временем factory нужно подправлять;
    • конфигурация это всегда словарь где и ключи и значения – строки, таким образом возникают неопределенности если вам нужны юникод-значения;
    • если в конфигурации неплохо бы применить список или еще какое значение типом посложнее, то придется изобретать кодирование такого значения для ini формата;
  • затем нужно создать entry point в setup.py для вашего пакета,
  • задокументировать это,
  • сослаться на него в конфигурации.
• Для использования приложения надо знать имя его entry point, как именно его конфигурировать итп. Таким образом возникает необходимость в еще одном наборе документации к приложению. Впрочем, чаще всё равно приходится читать исходники.
• Также есть сложности с повторным использованием блоков конфигурации, например, если нужно использовать одну и ту же базу данных в различных приложениях. Минимальная поддержка есть, но нельзя скажем параметризовать включаемый конфигурационный файл. Также, например, не смотря на то, что мы можем использовать одну и ту же БД в разных приложениях, они будут использовать раздельные пулы соединений.

Хотя часть этих проблем может быть решена конфигурацией в другом виде, например XML, большая часть проблем неизбежна при использовании отдельного языка для конфигурации приложений. Если же для конфигурации использовать Python-скрипты, то все упомянутые проблемы решаются сами собой – повторное использование параметризованных блоков конфигурации превращается ни во что иное как определение и вызовы функций. Не нужны никакие уловки для построения более сложных структур данных. Использование точек входа становится необязательным. И именно так работают wsgi-скрипты для mod_wsgi. Такое решение, кажущееся на первый взгляд кустарным, оказывается гораздо более мощным и удобным в использовании, чем любая возможная альтернатива. Мы теряем возможности PasteScript по управлению демонами сервера приложений, но это нас не беспокоит, так как теперь они управляются совместно с Apache, для их перезапуска применяется привычное sudo service apache2 force-reload.

Что до конфигурации приложений непрограммистами, то править файл с синтаксисом Python ничуть не сложнее чем аналогичный INI.

Запуск WSGI-скриптов без Apache

Что ж, с развертыванием на сервере более-менее ясно, а как быть с разработкой? Будем поднимать локальный сервер, настраивать его, перезапускать всякий раз когда вносим в код изменения? Я считаю что не стоит, и потому привожу свой модуль для исполнения wsgi-скриптов (это сокращенный, но рабочий вариант):

import sys
import os
from time import sleep
from traceback import print_exc

from paste.httpserver import serve
from paste.evalexception import EvalException
from paste.debug.prints import PrintDebugMiddleware
from paste import reloader

def run_script(script):
    if not os.path.isfile(script):
        print script, "does not exist"
        sys.exit(1)
    reloader.install()
    reloader.watch_file(script)

    script_locals = {}
    execfile(script, {'__file__': script}, script_locals)
    app = script_locals['application']
    app = EvalException(app)
    app = PrintDebugMiddleware(app)
    serve(app)

if __name__ == '__main__':
    try:
        run_script(sys.argv[0])
    except SystemExit, exc:
        raise exc
    except:
        print_exc()
        print '-' * 20, 'Restarting in 5 secs..', '-' * 20
        sleep(5)
        sys.exit(3)

Сохраним этот файл как run_wsgiscript.py там, где он будет доступен импортированию. Лучше оформить его как пакет, но самым простым вариантом будет разместить его в site-packages.

Такой скрипт загружает WSGI приложение образом аналогичным mod_wsgi, но в дополнение он оборачивает его парой отладочных middleware и запускает HTTP-сервер (по умолчанию на 8080-м порту). Также, благодаря paste.reloader, раз в секунду будет проверяться наличие изменений в самом скрипте и загруженных им модулях. Если такие изменения появятся, то скрипт выйдет с кодом ошибки 3; подразумевается, что внешний, вызывающий его скрипт воспринимает это как сигнал к перезапуску, о чем чуть дальше. Если при загрузке скрипта произошла ошибка (обычно это происходит если во внесенных изменениях есть синтаксическая ошибка), то на консоль будет выведен трейсбек и наш модуль выдержит пятисекундную паузу перед перезапуском (чтобы дать спокойно прочитать где была ошибка).

Последняя недостающая часть нашей системы – это внешний скрипт который перезапукает наш модуль. Я разрабатываю под Windows и пользуюсь таким (файл run-wsgi.bat):

@echo off
:repeat
    python -m run_wsgiscript %1
if %errorlevel% == 3 goto repeat

Если всё еще сохранилась неясность почему и как это сделано, просто посмотрите краткую документацию paste.reloader – мы просто применили эту систему к загрузке wsgi скриптов.

Если кто захочет оформить это всё в виде пакета – сообщите, я тоже поучаствую.

SciTE

Тем, кто, как и я, использует в работе SciTE, будет удобно добавить в его конфигурацию следующие строки, которые добавят wsgi -скриптам корректную подсветку и позволят запускать их по F5:

file.patterns.py=*.py;*.pyw;*.wsgi
command.go.*.wsgi=run-wsgi.bat "$(FilePath)"
command.go.subsystem.*.wsgi=2

WSGI-скрипт

На всякий случай, упреждая возможные вопросы, приведу пример скрипта. Поскольку wsgi-скрипт это полноценный питоновский файл, то мы можем определить WSGI приложение прямо в нем. Т.е. любой из примеров приведенных в предыдущих статьях можно использовать таким образом. Только теперь там, где мы вызывали paste.httpserver.serve(APP) нужно писать application = APP. Например вот наш самый первый пример в виде WSGI-скрипта (добавилась последняя строка кода):

import cgi
def hello_app(environ, start_response):
    start_response('200 OK', [('Content-type', 'text/plain')])
    yield "Hello, "
    form = cgi.FieldStorage(environ=environ)
    name = form.getfirst('name', 'stranger')
    yield name

application = hello_app

В Apache тоже ничего мудрить не надо, для начала достаточно такого:

WSGIScriptAlias /path-to-app /home/user/public/hello.wsgi

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

Следующая запланированная статья будет о создании WSGI middleware.

До сих пор в примерах мы почти не занимались собственно ответами, перекладывая эту задачу на какие-то уже существующие приложения. Как уже было упомянуто в