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

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

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

Плюс CGI – простота: написать программу, использующую 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. На самом деле это не так. Он внедряет интерпретатор в процесс Apache, тем самым ускоряя запросы, так как не нужно запускать интерпретатор Python для каждого запроса. С другой стороны, это совсем не «Python, перемешанный с HTML», как это часто делается в PHP. Эквивалент этого в 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 -*-

import sys, os
from cgi import escape
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>{0}</th><td>{1}</td></tr>'.format(
             escape(k), escape(v))
    yield '</table>'

WSGIServer(app).run()

mod_wsgi¶

mod_wsgi – это попытка избавиться от низкоуровневых шлюзов. Поскольку FastCGI, SCGI, mod_python в основном используются для развёртывания WSGI-приложений, mod_wsgi был создан для прямого встраивания WSGI-приложений в веб-сервер Apache. Преимущество этого подхода в том, что WSGI-приложения можно развёртывать гораздо проще, поскольку он специально спроектирован для размещения WSGI-приложений – в отличие от других низкоуровневых методов, которые используют связующий код для размещения WSGI-приложений (например, flup, упомянутый ранее). Недостаток в том, что mod_wsgi ограничен веб-сервером Apache; другим серверам потребуются собственные реализации 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. Хотя теперь в него включена поддержка WSGI, старым версиям требовался отдельный код для работы на CGI, mod_python, FastCGI и в автономном режиме. Теперь всё это возможно с помощью WSGI и уже написанных шлюзов. Для работы с FastCGI можно использовать flup, а для запуска автономного сервера wsgiref – самый подходящий вариант.

Шаблоны¶Templates

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

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

# простой шаблон
template = "<html><body><h1>Hello {who}!</h1></body></html>"
print(template.format(who="Reader"))

Стандартная библиотека Python также включает более продвинутые шаблоны, доступные через string.Template, но в HTML-шаблонах необходимо использовать условные конструкции и циклы, такие как for и if. Поэтому требуется какой-либо шаблонизатор.

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

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

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

Часто используются реляционные базы данных, такие как MySQL или PostgreSQL, благодаря их хорошей производительности при работе с очень большими базами данных, состоящими из миллионов записей. К ним выполняются запросы на языке SQL. Программисты Python в целом не любят SQL слишком сильно, они предпочитают работать с объектами. Сохранять Python-объекты в базу данных можно с помощью технологии, называемой ORM. ORM преобразует все объектно-ориентированные обращения в SQL-код за кулисами, пользователю не нужно думать об этом. Большинство фреймворков используют ORM, и это работает достаточно хорошо.

Вторая возможность – использовать файлы, сохраняемые на жёстком диске (иногда называемые плоскими файлами). Это очень просто, но не слишком быстро. Существует даже небольшая база данных под названием SQLite, которая входит в состав Python в модуле sqlite и использует всего один файл. Эту базу данных можно использовать для хранения объектов через ORM, и у неё нет других зависимостей. Для небольших сайтов SQLite вполне достаточно. Но это не единственный способ сохранения данных в файловой системе. Иногда достаточно обычных текстовых файлов.

Третья и наименее используемая возможность – так называемые объектно-ориентированные базы данных. Такие базы данных хранят сами объекты, а не отношения, которые OR-отображение создаёт между строками в базе данных. Это даёт преимущество: почти все объекты могут быть сохранены простым способом, в отличие от реляционных баз данных, где некоторые объекты очень сложно представить с помощью ORM.

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

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

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