HOWTO Использование Python в вебе¶HOWTO Use Python in the web

Общий шлюзовой интерфейс¶Common Gateway Interface

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

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

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

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

# включить отладку
import cgitb
cgitb.enable()

print "Content-Type: text/plain;charset=utf-8"
print

print "Hello World!"

mod_python¶

Люди, пришедшие из PHP, часто с трудом понимают, как использовать Python в вебе. Их первая мысль обычно – mod_python, потому что они считают, что это аналог mod_php. На самом деле между ними много различий. Что делает mod_python, так это встраивает интерпретатор в процесс Apache, ускоряя запросы за счет того, что не нужно запускать интерпретатор Python для каждого запроса. С другой стороны, это не «Python, смешанный с HTML» в том смысле, в котором PHP часто смешивают с HTML. Эквивалент в Python – это шаблонизатор. mod_python сам по себе гораздо мощнее и предоставляет больше доступа к внутренним механизмам Apache. Он может эмулировать CGI, работать в режиме «Python Server Pages» (похожем на JSP), который представляет собой «HTML, переплетенный с Python», и имеет «Publisher», который назначает один файл для приема всех запросов и решения, что с ними делать.

У mod_python есть некоторые проблемы. В отличие от интерпретатора PHP, интерпретатор Python использует кэширование при выполнении файлов, поэтому изменения в файле потребуют перезапуска веб-сервера. Другая проблема – это основная концепция: Apache запускает дочерние процессы для обработки запросов, и, к сожалению, каждый дочерний процесс должен загружать весь интерпретатор Python, даже если он его не использует. Это замедляет весь веб-сервер. Еще одна проблема заключается в том, что mod_python привязан к конкретной версии libpython, поэтому невозможно переключиться со старой версии на новую (например, с 2.4 на 2.5) без перекомпиляции mod_python. mod_python также привязан к веб-серверу Apache, поэтому программы, написанные для mod_python, не могут легко работать на других веб-серверах.

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

FastCGI и SCGI¶FastCGI and SCGI

FastCGI и SCGI пытаются решить проблему производительности CGI иным способом. Вместо встраивания интерпретатора в веб-сервер они создают долгоживущие фоновые процессы. В веб-сервере по-прежнему есть модуль, который позволяет веб-серверу «общаться» с фоновым процессом. Поскольку фоновый процесс не зависит от сервера, он может быть написан на любом языке, включая Python. Языку просто нужна библиотека, обрабатывающая взаимодействие с веб-сервером.

Разница между FastCGI и SCGI очень мала, поскольку SCGI – это, по сути, просто «упрощённый FastCGI». Из-за ограниченной поддержки SCGI веб-серверами большинство людей вместо него используют FastCGI, который работает так же. Почти всё, что применимо к SCGI, применимо и к FastCGI, поэтому мы рассмотрим только последний.

В наши дни FastCGI никогда не используется напрямую. Так же, как и mod_python, он используется только для развертывания WSGI-приложений.

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

from cgi import escape
import sys, os
from flup.server.fcgi import WSGIServer

def app(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])

    yield '<h1>FastCGI Environment</h1>'
    yield '<table>'
    for k, v in sorted(environ.items()):
        yield '<tr><th>%s</th><td>%s</td></tr>' % (escape(k), escape(v))
    yield '</table>'

WSGIServer(app).run()

mod_wsgi¶

mod_wsgi – это попытка избавиться от низкоуровневых шлюзов. Учитывая, что FastCGI, SCGI и mod_python в основном используются для развёртывания WSGI-приложений, mod_wsgi был создан для прямого встраивания WSGI-приложений в веб-сервер Apache. mod_wsgi специально разработан для размещения WSGI-приложений. Он делает развёртывание WSGI-приложений намного проще, чем развёртывание с использованием других низкоуровневых методов, требующих связующего кода. Недостаток в том, что mod_wsgi ограничен веб-сервером Apache; другим серверам потребуются собственные реализации mod_wsgi.

mod_wsgi поддерживает два режима: встроенный режим, при котором он интегрируется с процессом Apache, и режим демона, который больше похож на FastCGI. В отличие от FastCGI, mod_wsgi самостоятельно управляет рабочими процессами, что упрощает администрирование.

WSGI-серверы¶WSGI Servers

Код, используемый для подключения к различным низкоуровневым шлюзам, таким как CGI или mod_python, называется WSGI-сервером. Один из таких серверов – flup, который поддерживает FastCGI и SCGI, а также AJP. Некоторые из этих серверов написаны на Python, как flup, но существуют и другие, написанные на C и используемые в качестве готовой замены.

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

Пример: MoinMoin¶Case study: MoinMoin

Что даёт WSGI разработчику веб-приложений? Давайте взглянем на приложение, которое существует уже некоторое время и было написано на Python без использования WSGI.

Один из самых популярных пакетов вики-программного обеспечения – MoinMoin. Он был создан в 2000 году, то есть примерно на три года раньше WSGI. В старых версиях требовался отдельный код для работы с CGI, mod_python, FastCGI и в автономном режиме.

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

Шаблоны¶Templates

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

Python уже включает два способа создания простых шаблонов:

>>> template = "<html><body><h1>Hello %s!</h1></body></html>"
>>> print template % "Reader"
<html><body><h1>Hello Reader!</h1></body></html>

>>> from string import Template
>>> template = Template("<html><body><h1>Hello ${name}</h1></body></html>")
>>> print template.substitute(dict(name='Dinsdale'))
<html><body><h1>Hello Dinsdale!</h1></body></html>

Для генерации сложного HTML на основе нетривиальных данных модели обычно требуются условные конструкции и циклы, такие как for и if в Python. Шаблонизаторы (template engines) поддерживают шаблоны такой сложности.

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

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

Популярные шаблонизаторы включают:

• Mako

• Genshi

• Jinja

Сохранение данных¶Data persistence

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

Часто используются реляционные базы данных, такие как MySQL или PostgreSQL, благодаря их хорошей производительности при работе с очень большими базами данных, содержащими миллионы записей. Существует также небольшая база данных SQLite, которая входит в состав Python в модуле sqlite3 и использует только один файл. У нее нет других зависимостей. Для небольших сайтов SQLite вполне достаточно.

Relational databases are queried using a language called SQL. Python programmers in general do not like SQL too much, as they prefer to work with objects. It is possible to save Python objects into a database using a technology called ORM (Object Relational Mapping). ORM translates all object-oriented access into SQL code under the hood, so the developer does not need to think about it. Most frameworks use ORMs, and it works quite well.

Второй вариант – хранение данных в обычных текстовых файлах (иногда называемых «плоскими файлами»). Для простых сайтов это очень просто, но может оказаться сложным, если веб-сайт выполняет множество обновлений хранящихся данных.

Третий вариант – объектно-ориентированные базы данных (также называемые «объектными базами данных»). Они хранят данные объектов в форме, близкой к тому, как объекты структурированы в памяти во время выполнения программы. (В отличие от ORM, которые хранят данные объектов как строки в таблицах и связи между этими строками.) Прямое сохранение объектов имеет преимущество: почти все объекты могут быть сохранены простым способом, в отличие от реляционных баз данных, где некоторые объекты очень сложно представить.

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

Некоторые известные фреймворки¶Some notable frameworks

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