Веб-программирование. Язык программирования Python: разработка веб-приложений для нового поколения

В статье хотелось бы поднять вопросы отличия использования Python для web-разработки по сравнению с оной на PHP. Надеюсь, статья не приведет к холиварам, так как она вовсе не о том, какой язык лучше или хуже, а исключительно о технических особенностях Python.

Немного о самих языках

PHP - веб-ориентированный язык, создан, чтобы умирать (в хорошем смысле слова). С низкоуровневой точки зрения приложение на PHP представляет собой скорее набор отдельных скриптов возможно с единой семантической точкой входа.

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

Исходя из вышеописанных особенностей вытекают и различия в обработке ошибок в web-приложениях. В PHP существует целый зоопарк типов ошибок (errors, exceptions), далеко не каждую из которых можно перехватить, хотя это (невозможность перехвата) и не имеет большого значения, так как приложение живет ровно столько, сколько обрабатывается один запрос. Неперехваченная ошибка просто приводит к досрочному выходу из обработчика, и удалению приложения из памяти. Новый запрос будет обрабатываться новым «чистым» приложением. В Python же приложение постоянно находится в памяти, обрабатывая множество запросов без «перезагрузки». Таким образом поддерживать правильное предсказуемое состояние приложения крайне важно. Все ошибки используют стандартный механизм исключений и могут быть перехвачены (разве что за исключением SyntaxError). Неперехваченная ошибка приведет к завершению приложения, которое понадобится перезапускать извне.

Существует множество способов «приготовить» PHP и Python для веба. Далее я остановлюсь на двух наиболее мне знакомых (и кажется наиболее популярных) - PHP + FastCGI (php-fpm) и Python + WSGI (uWSGI). Конечно же, перед обоими этими связками предполагается наличие фронтенд-сервера (например, Nginx).

Поддержка многопоточности Python

Запуск сервера приложений (например, uWSGI) приводит к загрузке интерпретатора Python в память, а затем загрузке самого web-приложения. Обычно bootstrap-модуль приложения импортирует необходимые ему модули, производит вызовы инициализации и в итоге экспортирует подготовленный callable объект, соответствующий спецификации WSGI. Как известно, при первом импорте Python-модулей, код внутри них исполняется, в том числе создаются и инициализируются значениями переменные. Между двумя последовательными HTTP-запросами состояние интерпретатора не сбрасывается, следовательно сохраняются значения всех переменных уровня модуля.

Напишем простейшее WSGI-приложение, которое наглядно продемонстрирует вышеописанное на примере:

N = 0 def app(env, start_response): global n n += 1 response = "%.6d" % n start_response("200 OK", [("Content-Type", "text/plain")]) return
Здесь n является переменной модуля и она будет создана со значением 0 при загрузке приложения в память следующей командой:

Uwsgi --socket 127.0.0.1:8080 --protocol http --single-interpreter --processes 1 -w app:app
Само приложение просто выводит на страницу значение переменной n . Для заядлых PHP программистов оно выглядит бессмысленным, так как «должно» каждый раз выводить на страницу строку «000001».

Проведем тест:

Ab -n 500 -c 50 http://127.0.0.1:8080/ curl http://127.0.0.1:8080
В результате мы получим строку «000501» , что подтверждает наше утверждение, о том, что приложение находится загруженным в память uwsgi и сохраняет свое состояние между запросами.

Если запустить uWSGI с параметром --processes 2 и провести тот же тест, то несколько последовательных вызовов curl покажут, что мы имеем уже 2 различные возрастающие последовательности. Так как ab посылает 500 запросов, примерно половина из них приходится на один процесс uWSGI, а остальные - на второй. Ожидаемые значения, возращаемые curl будут примерно «000220» и «000280» . Интерпретатор Python, судя по всему, один на процесс, и мы имеем 2 независимых окружения и реальную параллельную обработку запросов (в случае многоядерного процессора).

Python поддерживает потоки, как часть языка. Классическая реализация (CPython) использует нативные потоки OS, но есть GIL - в один момент времени выполняется только один поток. При этом все равно возможны проблемы race condition, так как даже n += 1 не является атомарной операцией.

Дизассемблируем python код

«Дизассемблируем» наше WSGI-приложение:
import dis n = 0 def app(env, start_response): global n n += 1 return if "__main__" == __name__: print(dis.dis(app))
8 0 LOAD_GLOBAL 0 (n) 3 LOAD_CONST 1 (1) 6 INPLACE_ADD 7 STORE_GLOBAL 0 (n) 10 10 LOAD_GLOBAL 1 (bytes) 13 LOAD_GLOBAL 2 (str) 16 LOAD_GLOBAL 0 (n) 19 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 22 LOAD_CONST 2 ("utf-8") 25 CALL_FUNCTION 2 (2 positional, 0 keyword pair) 28 BUILD_LIST 1 31 RETURN_VALUE
Видно, что инкремент в нашей программе занимает 4 операции. Прерывание GIL может наступить на любой из них.


Увеличение количества потоков при отсуствии ожидания IO в коде обработчиков HTTP-запросов не приводит к ускорению обработки (а скорее даже ее замедляет, так как потоки могут «толкаться», переключая контексты). Реальной параллельности потоки в следствие ограничеия GIL не создают, хоть и являются не green thread"ами, а настоящими потоками OS.

Проведем еще один тест. Запустим uwsgi с 1 процессом, но 10 потоками-обработчиками в нем:

Uwsgi --socket 127.0.0.1:8080 --protocol http --single-interpreter --processes 1 --threads 10 -w app:app
и выполним с помощью ab 5000 запросов к приложению.

Ab -n 5000 -c 50 http://127.0.0.1:8080/
Последующие запросы curl 127.0.0.1 :8080 покажут, что мы имеем только одну возрастающую последовательность, значение которой <= 5000 (меньше 5000 оно может быть в случае race condition на инкременте).

Влияние языка на архитектуру приложения

Каждый HTTP-запрос обрабатывается в отдельном потоке (справедливо и для процессов, так как процесс имеет минимум 1 поток). При этом каждый поток за время своей жизни (которое в идеальных условиях совпадает со временем жизни всего uwsgi приложения) обрабатывает множество HTTP-запросов, сохраняя свое состояние (т.е. значения переменных уровня модулей) от запроса к запросу. В этом заключается чуть ли не основное отличие от модели обработки HTTP-запросов в PHP, где каждый запрос приходит новое только что проинициализированное окружение и загрузку приложения необходимо выполнять каждый раз заново.

Типичным подходом в крупных web-приложениях на PHP является использование Dependency Injection Container для управления инициализацией и доступом к уровню сервисов приложения. Наглядным примером является Pimple . На каждый HTTP-запрос первым делом выполняется код инициализации, регистрирующий все доступные сервисы в контейнере. Далее по мере необходимости осуществляется доступ к объектом сервисов (lazy) в контроллерах. Каждый сервис может зависеть от других сервисов, зависимости разрешаются опять же через контейнер в коде инициализации сервиса-агрегата.

// Определяем сервисы $container["session_storage"] = function ($c) { return new SessionStorage("SESSION_ID"); }; $container["session"] = function ($c) { return new Session($c["session_storage"]); }; // Используем сервисы class MyController { public function __construct() { // get the session object $this->session = $container["session"]; // "тестриуемость" страдает, но не суть } }
Благодаря контейнеру, можно обеспечить единовременное создание объектов и возвращение уже готовых объектов на каждое последующее обращение к сервису (если необходимо). Но эта магия работает только в рамках одного HTTP-запроса, поэтому сервисы можно без проблем инициализировать специфичными для запроса значениями. Такие значения зачастую - это текущий авторизованный пользователь, сессия текущего пользователя, собственно HTTP-запрос и пр. В конце запроса сервисы все равно будут разрушены, а в начале обработки следующего запроса - созданы и проинициализированы новые. К тому же можно практически не беспокоиться об утечках памяти, если обработка одного HTTP-запроса умещается в отведенные для скрипта лимиты, так как создание сервисов происходит по требованию (lazy) и на один запрос каждый необходимый сервис скорее всего будет создан только в единственном экземпляре.

Теперь, принимая во внимание вышеописанную поточную модель Python, можно заметить, что использование аналогичного подхода в Python web-приложении не возможно без дополнительных усилий. Если контейнер будет являться переменной уровня модуля (что выглядит вполне логично), все сервисы, которые он содержит, не могут быть проинициализированы специфичными для текущего запроса значениями, так как сервис будет являться разделяемым ресурсом между несколькими потоками, выполяющими обработку нескольких HTTP-запросов псевдо-параллельно. На первый взгляд существует два способа справиться с этой проблемой - сделать объекты сервисов независимыми от текущего HTTP-запроса (зависимыми остануться вызовы методов сервисов, а стековые переменные, используемые в методах, не являются разделяемыми ресурсами) или же сделать контейнер - ресурсом потока, а не процесса (тогда каждый поток будет общаться только со своим независимым набором сервисов, а в один момент времени один поток может обрабатывать только один HTTP-запрос).

Кажущийся плюс первого подхода - сервисы инициализируются только один раз за все время жизни uwsgi процесса. Возможна также экономия памяти (так как имеем только один набор сервисов на все потоки). С другой стороны обработка конкретного HTTP-запроса требует лишь какого-то (скорее всего небольшого) поднможества всех доступных сервисов. Если же приложение достаточно большое и обладает внушительным количеством сервисов, то после обработки определенного числа HTTP-запросов, подавляющее большинство сервисов окажется проинициализировнными и находящимися в памяти процесса. Выглядит так, что это может оказаться серьезной проблемой.

Второй подход можно реализовать с использованием

Данная статья посвящена трем важным в разработке приложений понятиям: Python, а также веб-серверам и наиболее важным их отличиям.

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

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

Python Web Server Gateway Interface v1.0 (WSGI)

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

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

В начале этого века были приложены все усилия, чтобы, наконец, представить публике Python Enhancement Proposal (PEP) 333.

Из PEP (Python Enhancement Proposal) 333:

This document specifies a proposed standard
interface between web servers and Python web
applications or frameworks, to promote web
application portability across a variety of
web servers.

Как говорится в РЕР, этот новый стандарт обеспечивает переносимость между веб-серверами и веб-приложениями Python. Мощные функции данного стандарта и его широкое внедрение по сравнению с предыдущими серьезно повлияли на развитие серверов: на сегодняшний день существует много (возможно, даже слишком много) веб-серверов, готовых сделать всю работу самостоятельно.

Сравнение

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

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

Веб-серверы (в алфавитном порядке)

CherryPy WSGI -сервер

Что это такое?

На самом деле, CherryPy – это фреймворк. Тем не менее, он полностью автономен (то есть, может работать сам по себе, в том числе на стадии производства, и не требует дополнительного программного обеспечения). Это осуществляется благодаря собственному веб-серверу WSGI, совместимому с HTTP/1.1. Проект CherryPy описывает его как «готовый к производству высокоскоростной общий HTTP-сервер». Поскольку это WSGI-сервер, он может обслуживать любое другое приложение Python WSGI, не привязываясь к фреймворку для разработки приложений CherryPy.

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

Gunicorn

Что это такое?

Gunicorn – автономный веб-сервер с обширной функциональностью, предоставленной в удобном виде. Он использует pre-fork модель (это значит, что что главный процесс управляет инициированными рабочими процессами различного типа, которые затем обрабатывают запросы). И все это можно настроить и адаптировать относительно потребностей проекта и разнообразных сценариев производства.

Почему нужно рассмотреть возможность его использования?

  • Он поддерживает WSGI и может быть использован с любым приложением и фреймворком Python на основе WSGI.
  • Это также полноценная замена Paster (например, Pyramid), сервера разработки Django, web2py, и так далее.
  • Предлагает широкий выбор различных типов «исполнителей»/конфигураций и автоматическое управление рабочими процессами.
  • Поддерживает HTTP/1.0 и HTTP/1.1 с помощью синхронных и асинхронных исполнителей.
  • Поставляется с поддержкой SSL
    Расширяется с помощью специальных точек входа.
    Интуитивно понятен, имеет четкую архитектуру.

Tornado (HTTP- сервер)

Что это такое?

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

Почему нужно рассмотреть возможность его использования?

  • Необходим при работе с фреймворком Tornado;
  • Удобен для приложений, которым нужен асинхронный режим работы.

Хотя, в таких случаях можно также использовать Gunicorn с асинхронными исполнителями Tornado.

Twisted Web

Что это такое?

Twisted Web – это веб-сервер, который поставляется с сетевой библиотекой Twisted. Тогда как сама библиотека Twisted является «событийно-управляемым сетевым механизмом», сервер Twisted Web работает на WSGI, следовательно, может содержать другие веб-приложения Python.

Почему нужно рассмотреть возможность его использования?

  • Это простой в использовании, надежный и зрелый продукт.
  • Может запускать приложения WSGI Python.
  • Может использоваться как фреймворк веб-сервера Python, что позволяет запрограммировать его на обслуживание пользовательского HTTP.
  • Простое и быстрое создание прототипа с помощью Python Scrips (.rpy), что выполняется по запросам HTTP.
  • Обладает возможностями прокси и инвертированного прокси-сервера.
  • Поддерживает Virtual Hosts.
  • Обслуживает Perl, PHP и т.п. через программный интерфейс приложения twisted.web.twcgi.

uWSGI

Что это такое?

Несмотря на очень запутанное соглашение об именах, сам uWSGI является обширным проектом, который состоит из большого количества компонентов, которые предоставляют полный набор программного обеспечения для построения хостинговых услуг. Один из этих компонентов, сервер uWSGI, запускает приложения Python WSGI. Он может использовать различные протоколы, в том числе и собственный протокол uwsgi, идентичный SCGI. Поскольку автономные HTTP-серверы по сравнению с серверами приложений более популярны, веб-серверы NGINX и Cherokee разработаны как модульные, что позволяет uWSGI использовать собственный протокол с высокой производительностью и обеспечивает прямой контроль над процессами.

Почему нужно рассмотреть возможность его использования?

  • Поставляется с адаптером WSGI и полностью поддерживает приложения Python на WSGI.
  • Связан с libpython. Он загружает код приложения при запуске и действует как интерпретатор Python, а также анализирует входящие запросы и вызывает Python.
  • Поставляется с прямой поддержкой популярного веб-сервера NGINX (а также Cherokee и Lighttpd).
  • Написан на языке C.
  • Различные компоненты могут сделать гораздо больше, чем просто запуск приложения, что может быть полезно для расширения функций.
  • В настоящее время (по состоянию на конец 2013 года), uWSGI активно развивается, регулярно появляются новые версии.
  • Имеет различные механизмы для запуска приложений (асинхронного и синхронного).
  • Невысокое потребление памяти при запуске.

Waitress WSGI-сервер

Что это такое?

Waitress – это сервер Python WSGI. На первый взгляд может показаться, что он не обладает существенными отличиями, однако его философия разработки отделяет его от остальных серверов. Его целью является упрощение процессов разработки и производства, достаточно сложных на серверах Python. Для этого Waitress нейтрализует конфликты, вызванные различиями платформ (например, Unix vs. Windows), интерпретаторов (CPython vs. PyPy) и версий Python (версия 2 vs 3).

Почему нужно рассмотреть возможность его использования?

  • Это очень простой, минималистский сервер Python.
  • Поддерживает HTTP/1.0 and HTTP/1.1 (Keep-Alive).
  • Поставляется готовым к развертыванию производства с широким спектром поддержки платформы.
  • В отличие от CherryPy, он по своей сути независим от фреймворка.
  • Запускается на Windows и Unix, работает с интерпретаторами CPython и PyPy (только на Unix).
  • Поддерживает версии Python 2 и 3.

Модули для автономных серверов

mod _ python с адаптером WSGI (Apache ) (встраивание Python )

Простыми словами, mod_python – это модуль Apache, который встраивает Python непосредственно в сервер. Хотя использовать его не всегда рекомендуется, он может запускать приложения WSGI на Apache с помощью оболочек.

Среды Web-разработки на языке Python, Часть 1

Разработка для Web с помощью Django и Python

Среда Web-разработки Django на языке Python, от установки до законченного Web-сайта

Серия контента:

Проект Django представляет собой настраиваемую пользователем среду разработки. Он берёт начало из Web-сайта одной онлайн-газеты и был выпущен как система с открытым исходным кодом в июле 2005 года. Главные компоненты среды разработки Django следующие:

  • Объектно-реляционное отображение (object-relational mapping) для создания моделей
  • Безупречный интерфейс администратора, специально созданный для конечных пользователей
  • Элегантно спроектированный механизм адресования (URL)
  • Язык шаблонов, для дизайнеров
  • Система кэширования

Эта статья - первая из двух статей о среде Web-разработки на языке Python. Вторая статья представит вам среду разработки TurboGears.

Чтобы использовать и понимать код в данной статье, вам необходимо установить Python и знать, как им пользоваться на начальном уровне. Проверьте, есть ли у вас Python, и какой версии, набрав python -V . Минимальным требованием Django является версия 2.3.5, которая доступна вам на Web-сайте Python (см. ссылку в разделе в конце статьи). Вам также следует хотя бы немного быть знакомым с архитектурой MVC.

Установка Django

В этой статье используется разрабатываемая версия Django для того, чтобы воспользоваться преимуществами последних улучшений, внесённых в среду разработки Django. Я рекомендую вам использовать эту версию до появления версии 0.95. Узнайте о наличии последней версии Django на его Web-сайте (снова см. ссылку в ).

Чтобы скачать и установить Django вам нужно:

Листинг 1. Скачивание и установка Django
~/downloads# svn co http://code.djangoproject.com/svn/django/trunk/ django_src ~/downloads# cd django_src ~/downloads# python setup.py install

Инструмент администрирования Django

После установки Django вам необходим инструмент администрирования Django, а именно django-admin.py, добавленный в переменную окружения path. Листинг 2 показывает некоторые из команд, доступных инструменту администратора:

Листинг 2. Использование инструмента администрирования Django
~/dev$ django-admin.py usage: django-admin.py action actions: adminindex Prints the admin-index template snippet for the given model module name(s). ... snip ... startapp Creates a Django app directory structure for the given app name in the current directory. startproject Creates a Django project directory structure for the given project name in the current directory. validate Validates all installed models. options: -h, --help show this help message and exit --settings=SETTINGS Python path to settings module, e.g. "myproject.settings.main". If this isn"t provided, the DJANGO_SETTINGS_MODULE environment variable will be used. --pythonpath=PYTHONPATH Lets you manually add a directory the Python path, e.g. "/home/djangoprojects/myproject".

Проекты и приложения в Django

Чтобы начать проект Django, используйте команду программы django-admin startproject вот так:

Листинг 3.Создание проекта
~/dev$ django-admin.py startproject djproject

Показанная выше команда создает директорию под названием djproject, которая содержит файлы базовой конфигурации, необходимые для работы проекта Django:

Листинг 4. Содержание директории djproject
__init__.py manage.py settings.py urls.py

В этом проекте вы создадите приложение для отдела занятости, называемое "jobs." Для создания приложения используйте скрипт manage.py , который является специальным для проекта скриптом в django-admin.py, в котором автоматически задаётся файл settings.py:

Листинг 5. Использование manage.py с параметром startapp
~/dev$ cd djproject ~/dev/djproject$ python manage.py startapp jobs

Это создает костяк приложения с одним модулем Python для ваших моделей и другим для ваших видов (view). Директория jobs будет содаржать следующие файлы:

Листинг 6. Содержание директории приложения jobs
__init__.py models.py views.py

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

Чтобы Django знал о новом приложении, вам необходимо добавить строку в поле INSTALLED_APPS в файле settings.py. Для этого приложения для отдела занятости нужно добавить строку djproject.jobs:

Листинг 7. Добавление строки к settings.py
INSTALLED_APPS = ("django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.sites", "djproject.jobs",)

Создание модели

У Django есть своя собственная библиотека object-relational mapper (ORM), которая поддерживает динамический доступ к базам данных через объектный интерфейс Python. Интерфейс Python является очень удобным и эффективным, но вы также можете отказаться от него и напрямую использовать SQL при необходимости.

На данный момент ORM предоставляет поддержку для баз данных PostgreSQL, MySQL, SQLite, а также Microsoft® SQL.

Это пример использует SQLite, в качестве интерфейса к базе данных. SQLite является легковесной базой данных, не требующей конфигурации и располагается на диске в виде простого файла. Чтобы использовать SQLite, просто установите библиотеку pysqlite с помощью инструментов установки (setuptools) (см. дополнительную информацию об инструментах установки (setuptools) и, в частности, об инструменте easy_install , который вам необходимо установить отдельно, в разделе ):

easy_install pysqlite

Перед тем, как работать с моделью, сконфигурируйте базу данных в файле настроек. Для SQLite необходимо указывать только движок и имя базы данных.

Листинг 8. Конфигурирование базы данных в settings.py
DATABASE_ENGINE = "sqlite3" DATABASE_NAME = "/path/to/dev/djproject/database.db" DATABASE_USER = "" DATABASE_PASSWORD = "" DATABASE_HOST = "" DATABASE_PORT = ""

Это приложение для отдела занятости будет иметь два типа объектов: Местоположения (Locations) и Работы (Jobs). Местоположение включает в себя поля города, штата (по желанию), а также страны. Работа имеет местоположение, должность, описание и дату публикации.

Листинг 9. Модуль jobs/models.py
from django.db import models class Location(models.Model): city = models.CharField(maxlength=50) state = models.CharField(maxlength=50, null=True, blank=True) country = models.CharField(maxlength=50) def __str__(self): if self.state: return "%s, %s, %s" % (self.city, self.state, self.country) else: return "%s, %s" % (self.city, self.country) class Job(models.Model): pub_date = models.DateField() job_title = models.CharField(maxlength=50) job_description = models.TextField() location = models.ForeignKey(Location) def __str__(self): return "%s (%s)" % (self.job_title, self.location)

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

Чтобы увидеть схему базы данных для модели, запустите manage.py с командой sql . Схема пока еще не будет задействована.

Листинг 10. Просмотр схемы базы данных с помощью команды manage.py sql
~/dev/djproject$ python manage.py sql jobs BEGIN; CREATE TABLE "jobs_job" ("id" integer NOT NULL PRIMARY KEY, "pub_date" date NOT NULL, "job_title" varchar(50) NOT NULL, "job_description" text NOT NULL, "location_id" integer NOT NULL); CREATE TABLE "jobs_location" ("id" integer NOT NULL PRIMARY KEY, "city" varchar(50) NOT NULL, "state" varchar(50) NULL, "country" varchar(50) NOT NULL); COMMIT;

Для инициализации и установки модели, запустите команду синхронизирования базы данных syncdb:

~/dev/djproject$ python manage.py syncdb

Отметим, что команда syncdb просит вас создать учетную запись суперпользователя. Это происходит потому, что приложение django.contrib.auth, которое предоставляет базовые средства аутентификации пользователя, установлено по умолчанию в ваших настройках INSTALLED_APPS. Имя суперпользователя и пароль будут использоваться для регистрации в инструменте администратора, описанном в следующем разделе. Помните, что это имя и пароль суперпользователя Django, а не системы.

Наборы запросов

Модели Django обращаются к базе данных через изначально установленный Управляющий (Manager) класс, называемый objects . Например, чтобы вывести список всех Работ, вам нужно использовать метод all , принадлежащий менеджеру objects:

Листинг 11. Вывод всех работ (jobs)
>>> from jobs.models import Job >>> for job in Job.objects.all(): ... print job

Управляющий класс также имеет методы фильтрации, называемые filter (фильтрация) и exclude (исключение). Фильтрация получает все объекты, подходящие под условия, тогда как исключение дает все объекты, не подходящие под них. Нижеследующие запросы должны дать такие же результаты ("gte" означает "greater than or equal,"(больше или равно) и "lt" означает "less than")(меньше чем).

Листинг 12. Исключение и фильтрация работ (jobs)
>>> from jobs.models import Job >>> from datetime import datetime >>> q1 = Job.objects.filter(pub_date__gte=datetime(2006, 1, 1)) >>> q2 = Job.objects.exclude(pub_date__lt=datetime(2006, 1, 1))

Методы filter и exclude возвращают объекты QuerySet, которые можно связать в цепочку и которые могут даже представлять соединения. Запрос q4 , приведенный ниже, будет находить работы, начиная с 1-го января 2006 года, в г. Кливленд (Cleveland), штат Огайо:

Листинг 13. Снова исключение и фильтрация работ (jobs)
>>> from jobs.models import Job >>> from datetime import datetime >>> q3 = Job.objects.filter(pub_date__gte=datetime(2006, 1, 1)) >>> q4 = q3.filter(location__city__exact="Cleveland", ... location__state__exact="Ohio")

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

Эта леность является очень практичной в сочетании с рассекающей (slicing) функциональностью языка Python. Вместо того, чтобы запрашивать все записи, а затем отсекать нужные записи, нижеследующий код использует смещение (OFFSET), равное 5, и предел (LIMIT), равный 10, в настоящем запросе SQL, весьма улучшая качество выполнения.

Листинг 14. Python-рассечение
>>> from jobs.models import Job >>> for job in Job.objects.all() ... print job

Примечание: Используйте метод count , чтобы понять, сколько записей находятся в QuerySet. Метод len в Python делает полную оценку, а затем подсчитывает количество рядов, возращенных в виде записей, тогда как метод count делает действительный Подсчет (COUNT) SQL, который гораздо быстрее. И ваш администратор баз данных поблагодарит вас.

Листинг 15. Подсчет записей
>>> from jobs.models import Job >>> print "Count = ", Job.objects.count() # GOOD! >>> print "Count = ", len(Job.objects.all()) # BAD!

Для более подробной информации, см. раздел для ссылки на "Справочник по интерфейсу API базы данных" для Django.

Инструмент администратора

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

Инструмент администратора представляет собой приложение, которое идет вместе с Django. Перед тем, как его использовать, его необходимо установить так же, как и приложение jobs . Сперва нужно добавить модуль приложения (django.contrib.admin) в настройки INSTALLED_APPS:

Листинг 16. Изменения в settings.py
INSTALLED_APPS = ("django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.sites", "djproject.jobs", "django.contrib.admin",)

Чтобы сделать инструмент администратора доступным из адреса (URL) /admin, просто раскройте скобки комментария в строке, в предоставленном вам файле urls.py вашего проекта. В следующем разделе будет рассматриваться конфигурация URL более подробно.

Листинг 17. Использование urls.py, чтобы иструмент администратора стал доступным
from django.conf.urls.defaults import * urlpatterns = patterns("", (r"^admin/", include("django.contrib.admin.urls.admin")),)

Пиложение администратора имеет свою модель базы данных, которую необходимо установить. Снова используйте команду syncdb , чтобы завершить следующее:

python manage.py syncdb

Чтобы увидеть инструмент администратора, вы можете использовать тест-сервер, которая прилагается к Django.

Листинг 18. Использование тест-сервера, чтобы увидеть инструмент администратора
~/dev/djproject$ python manage.py runserver Validating models... 0 errors found. Django version 0.95 (post-magic-removal), using settings "djproject.settings" Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C (Unix) or CTRL-BREAK (Windows).

Теперь вы можете переместиться в инструмент администратора по адресу http://localhost:8000/admin и зарегистрироваться, используя данные администратора, созданные вами ранее. Вы заметите, что ни одна из ваших моделей не доступна для пользования.

Чтобы открыть доступ к классу через инструмент администратора, создайте для него подкласс Admin (Администратора). Затем вы можете настраивать то, как их можно администрировать добавлением характеристик классов к данному подклассу. Листинг 19 показывает, как добавлять класс Location (Местонахождения) к интсрументу администратора.

Листинг 19. Добасвление класса Location с помощью инструмента администратора
class Location(meta.Model): ... class Admin: list_display = ("city", "state", "country")

Теперь вы можете создавать, обновлять и удалять записи Местонахождения (Location) через интерфейс администратора.

Рисунок 1. Изменение местонахождений с помощью инструмента администратора

Вы можете выводить и сортировать Записи (Records) по городам, штатам и странам, в зависимости от характеристики класса list_display .

Рисунок 2. Вывод местонахождений с помощью инструмента администратора

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

Листинг 20. Опции для управления классами моделей
class Job(meta.Model): ... class Admin: list_display = ("job_title", "location", "pub_date") ordering = ["-pub_date"] search_fields = ("job_title", "job_description") list_filter = ("location",)

В соответствие с вышеупомянутыми настройками, при выводе записей работ (job) будут использоваться: заголовок работы (job), местонахождения и дата издания. Работы будут располагаться в порядке даты издания, начиная с самого последнего (знак минус означает - в порядке убывания). Пользователи могут найти работы по заголовку и описанию, а администраторы могут фильтровать записи, исходя из их местонахождения.

Рисунок 3. Вывод работ с помощью инструмента администратора

Проектирование своей схемы URL

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

Модуль urls.py создается и определяется в качестве начала отсчета конфигурации URL (с помощью значения ROOT_URLCONF в модуле settings.py). Единственное требование для файла конфигурации URL состоит в том, что он должен содержать объект, определяющий шаблоны, называемые urlpatterns .

Приложение управления работой (job) будет начинаться с index-видом и детальным (detail) видом, которые доступны через настоящие отображения URL:

  • /jobs index-вид: Отображает последние 10 работ
  • /jobs/1 детальный вид: Отображает работы с одним идентификационным номером (ID)

Оба этих вида (index и детальный вид) будут выполнены в модуле, называемом views.py в приложении работ. Выполнение этой конфигурации в файле urls.py проекта будут выглядеть следующим образом:

Листинг 21. Выполнение конфигурации видов в djproject/urls.py
from django.conf.urls.defaults import * urlpatterns = patterns("", (r"^admin/", include("django.contrib.admin.urls.admin")), (r"^jobs/$", "djproject.jobs.views.index"), (r"^jobs/(?P

Отметьте кусочек кода . Это понадобиться позже.

На практике лучше всего - вытаскивать шаблоны URL, специальные для приложений, и помещать их в само приложение. Это отделяет приложение от проекта и позволяет повторно его использовать. Файл конфигурации URL уровня приложений для работ (jobs) будут выглядеть так:

Листинг 22. Файл конфигурации URL уровня приложений, urls.py
from django.conf.urls.defaults import * urlpatterns = patterns("", (r"^$", "djproject.jobs.views.index"), (r"^(?P\d+)/$", "djproject.jobs.views.detail"),)

С тех пор, как методы видов исходят из одного модуля, для настройки djproject.jobs.views в качестве корневого имени модуля можно использовать первый аргумент, и Django использует его для того, чтобы искать методы index и detail:

Листинг 23. jobs/urls.py: поиск index и detail
from django.conf.urls.defaults import * urlpatterns = patterns("djproject.jobs.views", (r"^$", "index"), (r"^(?P\d+)/$", "detail"),)

Чтобы связать в одно целое адреса (URL), перечисленных выше работ (job), назад в проект, необходимо использовать функцию include . Адреса (URL) уровня приложений теперь связаны в разделе /jobs:

Листинг 24. djproject/urls.py: Связывание адресов (URL) обратно в проект
from django.conf.urls.defaults import * urlpatterns = patterns("", (r"^admin/", include("django.contrib.admin.urls.admin")), (r"^jobs/", include("djproject.jobs.urls")),)

Если вы попытаетесь войти на начальную (index) страницу (http://localhost:8000/jobs) на этом этапе, используя тест-сервер, вы получите ошибку, так как вид, который будет называться (djproject.jobs.views.index), еще не существует.

Выполнение видов

Вид представляет собой простой метод языка Python, который принимает объект отклика и отвечает за:

  • Любую бизнес-логику (явно или неявно)
  • Контекстный словарь с данными для шаблона
  • Рендеринг (rendering) шаблона с контекстом
  • Объект отклика, который пропускает отрендеренные (rendered) результаты обратно в среду разработки

В Django вызванный метод языка Python, когда запрашивается URL, называется видом , а страница, закаченная и отрендеренная, видом называется шаблоном . По этой причине, команда разработчиков Django говорила о Django, как о среде разработки с MVT (model-view-template - модель-вид-шаблон). С другой стороны, TurboGears называет свои методы контроллерами , а отрендеренные шаблоны видами , что действительно позволяет использовать аббревиатуру MVC. Разница лишь в использовании слов, но смысл остается тем же.

Самый простейший из возможных видов возвращает объект HttpResponse (http отклик), инициализированный в строковый тип. создайте следующий метод и сделайте из /jobs HTTP-запрос, чтобы проверить, что ваши файлы urls.py и views.py правильно настроены.

Листинг 25. jobs/views.py (v1)
from django.http import HttpResponse def index(request): return HttpResponse("Job Index View")

Следующий код получает последние 10 работ (job), рендерит их через шаблон и возвращает отклик. Это не будет работать без файла шаблона из .

Листинг 26. jobs/views.py (v2)
from django.template import Context, loader from django.http import HttpResponse from jobs.models import Job def index(request): object_list = Job.objects.order_by("-pub_date")[:10] t = loader.get_template("jobs/job_list.html") c = Context({ "object_list": object_list, }) return HttpResponse(t.render(c))

В вышеприведенном коде шаблон назван, как строковый jobs/job_list.html Рендеринг шаблона происходит в контексте списка работ (job), названном object_list . Отрендеренный шаблон строки попадает в конструктор HTTPResponse, который отправляется назад в клиент запроса с помощью среды разработки.

Этапы загрузки шаблона, создающие контекст и возвращающие новый объект отклика, перемещены ниже с помощью удобного метода, называемого render_to_response . Также новым является метод детального (detail) вида, который использует удобный для этого метод get_object_or_404 , чтобы осуществить выборку объекта Job, используя приведенные аргументы. Если объект не найден, то выдается ошибка 404. Эти два метода избавляют программу от большого количества стандартных кодов, используемых в большинстве Web-приложений.

Листинг 27. jobs/views.py (v3)
from django.shortcuts import get_object_or_404, render_to_response from jobs.models import Job def index(request): object_list = Job.objects.order_by("-pub_date")[:10] return render_to_response("jobs/job_list.html", {"object_list": object_list}) def detail(request, object_id): job = get_object_or_404(Job, pk=object_id) return render_to_response("jobs/job_detail.html", {"object": job})

Отметим, что detail берет object_id в качестве аргумента. Этот номер упоминался раньше, после URL-пути /jobs/ к файлу работ (job) urls.py. Он проходит дальше в метод get_object_or_404 в качестве первичного ключа (primary key - pk).

Приведенные выше виды все еще не будут работать, потому что шаблоны, которые они загружают и рендерят (jobs/job_list.html и jobs/job_detail.html) еще не существуют.

Создание шаблонов

Django предоставляет простой язык шаблонов, спроектированный для быстрого рендеринга и простоты использования. Шаблоны Django создаются из простого текста, встроенного в {{ переменные }} и {% тэги %} . Затем происходит замена переменных на значения, которые они несут. Тэги используются в качестве основы логики управления. Шаблоны можно использовать для генерирования любого формата текстов, включая HTML, XML, CSV и простой текст.

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

Листинг 28. Создание директории шаблонов в settings.py
TEMPLATE_DIRS = ("/path/to/devdir/djproject/templates/",)

Шаблоны в Django поддерживают концепцию, называемую наследованием шаблонов , которая позволяет дизайнерам сайтов создавать однородный вид и функциональность без повторения содержания в каждом из шаблонов. Вы можете использовать наследование, определяя документ скелета, или основы, с блочными тэгами. Эти блочные тэги заполняются шаблонами страниц с содержанием. Этот пример показывает скелет кода на HTML с блоками, называемыми title , extrahead и content:

Листинг 29. Документ скелета, templates/base.html
Company Site: {% block title %}Page{% endblock %} {% block extrahead %}{% endblock %} {% block content %}{% endblock %}

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

Листинг 30. Вспомогательный файл основы, templates/jobs/base.html
{% extends "base.html" %} {% block extrahead %} {% endblock %}

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

Теперь создайте 2 шаблона страниц для загрузки и рендеринга. Шаблон jobs/job_list.html просто выполняет итерацию через object_list (список объектов), который он получает через контекст, выдаваемый index-видом, а также отображает ссылку на каждую из страниц с подробной информацией о записи.

Листинг 31. Шаблон templates/jobs/job_list.html
{% extends "jobs/base.html" %} {% block title %}Job List{% endblock %} {% block content %}

Job List

    {% for job in object_list %}
  • {{ job.job_title }}
    • {% endfor %}
{% endblock %}

Страница jobs/job_detail.html показывает одну запись, называемую job (работа):

Листинг 32. Страница templates/jobs/job_detail.html
{% extends "jobs/base.html" %} {% block title %}Job Detail{% endblock %} {% block content %}

Job Detail

{{ job.job_title }} - {{ job.location }}
Posted: {{ job.pub_date|date:"d-M-Y" }}
{{ job.job_description }}
{% endblock %}

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

Универсальные виды

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

  • Страницы со списком/подробностями (как вышеприведенный пример)
  • Дробление записей по дате (полезно для новостных сайтов и блогов)
  • Создание, обновление и удаление - СОУ (Creation, update, and deletion - CRUD) объектов
  • Простой прямой рендеринг шаблонов или простое HTTP-перенаправление

Вместо создания методов стандартных видов, вся бизнес-логика находится в файле urls.py и управляется с помощью методов универсальных видов, поддерживаемых Django.

Листинг 33. Универсальные виды в jobs/urls.py
from django.conf.urls.defaults import * from jobs.models import Job info_dict = { "queryset": Job.objects.all(), } urlpatterns = patterns("django.views.generic.list_detail", (r"^$", "object_list", info_dict), (r"^(?P\d+)/$", "object_detail", info_dict),)

Три важных изменения в данном файле urls.py:

  • Объект отображения info_dict проходит через набор запросов, чтобы был открыт доступ для Jobs.
  • Он использует django.views.generic.list_detail вместо djproject.jobs.views .
  • Действительно вызванные виды - это object_list и object_detail .

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

  • Универсальный детальный (detail) вид ожидает аргумент с именем object_id .
  • Шаблоны следуют наименованию: app_label /model_name _list.html (jobs/job_list.html) app_label /model_name _detail.html (jobs/job_detail.html)
  • Шаблон списка управляет списком с именем object_list .
  • Детальный шаблон управляет объектом с именем object .

Больше опций можно задать через info_dict , включая значение paginate_by , которое определяет число объектов на странице.

Заключение

Следующая статья этого выпуска будет рассматривать TurboGears, другую среду Web-разработки на языке Python, и будет сравнивать его с Django.

Программирование на Python

Часть 11. Web-программирование: Django

Серия контента:

Одной из наиболее фундаментальных архитектур для приложений является так называемая архитектура модель-представление-контроллер (Model-View-Controller) или MVC, которая разделяет базовый функционал приложения на ряд отдельных компонентов. При этом достигается главная цель: одна модель на много приложений.

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

Отличительные особенности джанго:

  • любой запрос обрабатывается программно и перенаправляется на свой адрес(url);
  • разделение контента и представления с помощью шаблонов;
  • абстрагирование от низкого уровня баз данных.

Джанго-приложение состоит из четырех основных компонентов.

  1. Модель данных: данные являются сердцевиной любого современного Web-приложения. Модель – важнейшая часть приложения, которое постоянно обращается к данным при любом запросе из любой сессии. Любая модель является стандартным питоновским классом. Объектно-ориентированный маппер (ORM) обеспечивает таким классам доступ непосредственно к базам данных. Если бы не было ORM, программисту пришлось бы писать запросы непосредственно на SQL. Модель обеспечивает облегченный механизм доступа к слою данных, инкапсулирует бизнес-логику. Модель не зависит от конкретного приложения. Данными можно манипулировать даже из командной строки, не используя при этом Web-сервер.
  2. Представление (view): вьюхи в джанге выполняют разнообразные функции, в том числе контролируют запросы пользователя, выдают контекст в зависимости от его роли. View – это обычная функция, которая вызывается в ответ на запрос какого-то адреса (url) и возвращает контекст.
  3. Шаблоны: они являются формой представления данных. Шаблоны имеют свой собственный простой метаязык и являются одним из основных средств вывода на экран.
  4. URL: это всего лишь механизм внешнего доступа к представлениям (view). Встроенные в урлы регулярные выражения делают механизм достаточно гибким. При этом одно представление может быть сконфигурировано к нескольким урлам, предоставляя доступ различным приложениям. Здесь поддерживается философия закладок: урлы становятся как бы самодостаточными и начинают жить независимо от представления.

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

Сегодня мы рассмотрим следующие темы.

  1. Как инсталлировать джанго.
  2. Первое приложение.
  3. Подключение базы данных.
  4. Первое представление.
  5. Шаблоны.
  6. Администрирование.

1. Как инсталлировать джанго

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

После разархивации в каталоге проекта запустите команду:

setup.py install > import django

Проверка версии джанго:

> django.VERSION

На данный момент официальная стабильная версия – 1.1.1.

2. Первое приложение

Для создания первого приложения зайдем в свой домашний каталог и запустим команду:

django-admin.py startproject mysite

Будет создан подкаталог mysite, где и будет лежать приложение. Заходим в созданный каталог и видим следующую файловую структуру:

mysite/ __init__.py manage.py settings.py urls.py

Init__.py – пустой файл, который подключает текущий каталог как стандартный питоновский пакет.

manage.py – утилита, управляющая сайтом.

settings.py – конфигурация сайта.

urls.py – таблица урлов или таблица для всего контента сайта.

Для того чтобы загрузить наше Web-приложение, запустим команду:

python manage.py runserver Validating models... 0 errors found. Django version 1.1, using settings "mysite.settings" Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C.

Если теперь в браузере открыть адрес http://127.0.0.1:8000/, то убедимся в том, что приложение запущено: появится стандартное приглашение.

3. Подключение базы данных

Джанго поддерживает следующие серверы баз данных: PostgreSQL, SQLite, MySQL, Microsoft SQL Server, Oracle.

В нашем примере мы выбираем постгрес – не потому, что он лучше, это не имеет принципиального значения. Убедитесь в том, что постгрес уже установлен на вашей системе, в противном случае его нужно проинсталлировать. После этого в файле settings.py пропишем настройки для постгреса:

DATABASE_ENGINE = "postgresql_psycopg2" DATABASE_NAME = "mysite" DATABASE_USER = "postgres" TIME_ZONE = "Europe/Moscow" LANGUAGE_CODE = "ru-ru"

Запускаем две команды, которые создают базу данных mysite – постгрес перед этим, естественно, должен быть уже запущен:

psql -d template1 -U postgres -c "DROP DATABASE mysite;" psql -d template1 -U postgres -c "CREATE DATABASE mysite WITH OWNER postgres ENCODING="UNICODE";"

Запускаем команду, которая создает в этой базе около 10 системных таблиц:

python manage.py syncdb

4. Первое представление

Теперь сгенерируем каркас для нашего Web-приложения:

python manage.py startapp People

Внутри каталога mysite появится подкаталог People со следующей структурой:

People/ __init__.py models.py tests.py views.py

Добавим в settings.py последнюю строку, которая добавляет новый путь:

INSTALLED_APPS = ("django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.sites", "mysite.People")

В settings.py в качестве корневого адреса должен быть:

ROOT_URLCONF = "mysite.urls"

Создадим модель Person – стандартный питоновский класс с двумя атрибутами – имя, и-мейл. Файл models.py:

from django.db import models class Person(models.Model): name = models.CharField("name", max_length=200) email = models.EmailField("Email", blank=True) def __str__(self): return "%s" % (self.name)

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

python manage.py syncdb

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

Теперь напишем простейшее представление, которое выведет приглашение-файл views.py:

from django.shortcuts import HttpResponse from mysite.People.models import Person def index(request): html = "

People !!!

" return HttpResponse(html)

Добавим урл – файл urls.py:

from django.conf.urls.defaults import * urlpatterns = patterns("", (r"^People/$", "mysite.People.views.index"))

Вновь запускаем Web-приложение:

python manage.py runserver

Открываем адрес в браузере и видим приглашение:

http://127.0.0.1:8000/People/

5. Шаблоны

В корне каталога mysite создадим каталог templates. В файле settings.py добавим строку:

TEMPLATE_DIRS = ("/home/mysite/templates")

Добавленный путь должен быть абсолютным. В добавленный каталог положим файл person.htnl следующего содержания:

People !!!

Personal Information
  • Name: {{p.name}}
    		•
  • Email: {{ p.email }}

    • В нашем единственном представлении index мы сделаем изменения: создадим объект Person и передадим его в вызываемый шаблон в качестве параметра. В шаблоне мы берем атрибуты этого параметра с помощью префикса двойных кавычек:

    {{p.name}} {{p.email}}

    Файл views.py после подключения шаблона теперь будет выглядеть так:

    from mysite.People.models import Person from django.shortcuts import render_to_response, get_object_or_404 def index(request): person = Person() person.name = "Alex" person.email = "[email protected]" return render_to_response("person.html", {"p": person})

    После перезагрузки Web-страницы в браузере мы увидим эти атрибуты.

    6. Администрирование

    Администраторская часть в джанго по умолчанию отключена. Для ее включения добавим последнюю строку в settings.py:

    INSTALLED_APPS = ("django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.sites", "mysite.People", "django.contrib.admin")

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

    python manage.py createsuperuser

    После этого запустим команду:

    python manage.py syncdb

    Файл urls.py с добавленным админским функционалом будет иметь следующий вид:

    from django.conf.urls.defaults import * from django.contrib import admin admin.autodiscover() urlpatterns = patterns("", (r"^admin/", include(admin.site.urls)), (r"^People/$", "mysite.People.views.index"))

    Запускаем Web-приложение:

    python manage.py runserver

    Набираем в браузере адрес: http://127.0.0.1:8000/admin/. И попадаем на страницу логина. После ввода логина и пароля суперпользователя открывается админская часть. В ней можно добавлять и редактировать объекты.

    Заключение

    Итак, сегодня мы узнали, что такое Джанго и почему стоит остановить на нем свой выбор. Это бесплатный фреймворк, который поддерживает модель MVC, имеет несколько программных интерфейсов к различным базам данных, интуитивно понятный интерфейс администрирования с возможностью расширения, поддержку многоязычности и т.д. Этот Web-фреймворк обладает рядом преимуществ: джанго хорошо документирован – сайт разработчиков http://www.djangoproject.com/ тому подтверждение. Легкость установки и настройки помогают значительно экономить время. Малое число внешних зависимостей удобно для пользования: все, что нам нужно – это питон. На этом наш цикл статей можно считать завершенным. Конечно, автор не ставил перед собой задачи написать подробный учебник или справочник, скорее здесь речь идет о кратком вводном курсе для разработчиков, желающих освоить новый для себя инструмент.

    Код примеров проверялся на версии питона 2.6.

    Ресурсы для скачивания

    static.content.url=http://www.сайт/developerworks/js/artrating/

    Zone=Linux, Open source

    ArticleID=517107

    ArticleTitle=Программирование на Python: Часть 11. Web-программирование: Django

  • PHP ,
  • Python

    • Введение

    В статье хотелось бы поднять вопросы отличия использования Python для web-разработки по сравнению с оной на PHP. Надеюсь, статья не приведет к холиварам, так как она вовсе не о том, какой язык лучше или хуже, а исключительно о технических особенностях Python.

    Немного о самих языках

    PHP - веб-ориентированный язык, (в хорошем смысле слова). С низкоуровневой точки зрения приложение на PHP представляет собой скорее набор отдельных скриптов возможно с единой семантической точкой входа.

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

    Исходя из вышеописанных особенностей вытекают и различия в обработке ошибок в web-приложениях. В PHP существует целый зоопарк типов ошибок (errors, exceptions), далеко не каждую из которых можно перехватить, хотя это (невозможность перехвата) и не имеет большого значения, так как приложение живет ровно столько, сколько обрабатывается один запрос. Неперехваченная ошибка просто приводит к досрочному выходу из обработчика, и удалению приложения из памяти. Новый запрос будет обрабатываться новым «чистым» приложением. В Python же приложение постоянно находится в памяти, обрабатывая множество запросов без «перезагрузки». Таким образом поддерживать правильное предсказуемое состояние приложения крайне важно. Все ошибки используют стандартный механизм исключений и могут быть перехвачены (разве что за исключением SyntaxError). Неперехваченная ошибка приведет к завершению приложения, которое понадобится перезапускать извне.

    Существует множество способов «приготовить» PHP и Python для веба. Далее я остановлюсь на двух наиболее мне знакомых (и кажется наиболее популярных) - PHP + FastCGI (php-fpm) и Python + WSGI (uWSGI). Конечно же, перед обоими этими связками предполагается наличие фронтенд-сервера (например, Nginx).

    Поддержка многопоточности Python

    Запуск сервера приложений (например, uWSGI) приводит к загрузке интерпретатора Python в память, а затем загрузке самого web-приложения. Обычно bootstrap-модуль приложения импортирует необходимые ему модули, производит вызовы инициализации и в итоге экспортирует подготовленный callable объект, соответствующий спецификации WSGI. Как известно, при первом импорте Python-модулей, код внутри них исполняется, в том числе создаются и инициализируются значениями переменные. Между двумя последовательными HTTP-запросами состояние интерпретатора не сбрасывается, следовательно сохраняются значения всех переменных уровня модуля.

    Напишем простейшее WSGI-приложение, которое наглядно продемонстрирует вышеописанное на примере:

    N = 0 def app(env, start_response): global n n += 1 response = "%.6d" % n start_response("200 OK", [("Content-Type", "text/plain")]) return
    Здесь n является переменной модуля и она будет создана со значением 0 при загрузке приложения в память следующей командой:

    Uwsgi --socket 127.0.0.1:8080 --protocol http --single-interpreter --processes 1 -w app:app
    Само приложение просто выводит на страницу значение переменной n . Для заядлых PHP программистов оно выглядит бессмысленным, так как «должно» каждый раз выводить на страницу строку «000001».

    Проведем тест:

    Ab -n 500 -c 50 http://127.0.0.1:8080/ curl http://127.0.0.1:8080
    В результате мы получим строку «000501» , что подтверждает наше утверждение, о том, что приложение находится загруженным в память uwsgi и сохраняет свое состояние между запросами.

    Если запустить uWSGI с параметром --processes 2 и провести тот же тест, то несколько последовательных вызовов curl покажут, что мы имеем уже 2 различные возрастающие последовательности. Так как ab посылает 500 запросов, примерно половина из них приходится на один процесс uWSGI, а остальные - на второй. Ожидаемые значения, возращаемые curl будут примерно «000220» и «000280» . Интерпретатор Python, судя по всему, один на процесс, и мы имеем 2 независимых окружения и реальную параллельную обработку запросов (в случае многоядерного процессора).

    Python поддерживает потоки, как часть языка. Классическая реализация (CPython) использует нативные потоки OS, но есть GIL - в один момент времени выполняется только один поток. При этом все равно возможны проблемы race condition, так как даже n += 1 не является атомарной операцией.

    Дизассемблируем python код

    «Дизассемблируем» наше WSGI-приложение:
    import dis n = 0 def app(env, start_response): global n n += 1 return if "__main__" == __name__: print(dis.dis(app))
    8 0 LOAD_GLOBAL 0 (n) 3 LOAD_CONST 1 (1) 6 INPLACE_ADD 7 STORE_GLOBAL 0 (n) 10 10 LOAD_GLOBAL 1 (bytes) 13 LOAD_GLOBAL 2 (str) 16 LOAD_GLOBAL 0 (n) 19 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 22 LOAD_CONST 2 ("utf-8") 25 CALL_FUNCTION 2 (2 positional, 0 keyword pair) 28 BUILD_LIST 1 31 RETURN_VALUE
    Видно, что инкремент в нашей программе занимает 4 операции. Прерывание GIL может наступить на любой из них.


    Увеличение количества потоков при отсуствии ожидания IO в коде обработчиков HTTP-запросов не приводит к ускорению обработки (а скорее даже ее замедляет, так как потоки могут «толкаться», переключая контексты). Реальной параллельности потоки в следствие ограничеия GIL не создают, хоть и являются не green thread"ами, а настоящими потоками OS.

    Проведем еще один тест. Запустим uwsgi с 1 процессом, но 10 потоками-обработчиками в нем:

    Uwsgi --socket 127.0.0.1:8080 --protocol http --single-interpreter --processes 1 --threads 10 -w app:app
    и выполним с помощью ab 5000 запросов к приложению.

    Ab -n 5000 -c 50 http://127.0.0.1:8080/
    Последующие запросы curl 127.0.0.1 :8080 покажут, что мы имеем только одну возрастающую последовательность, значение которой <= 5000 (меньше 5000 оно может быть в случае race condition на инкременте).

    Влияние языка на архитектуру приложения

    Каждый HTTP-запрос обрабатывается в отдельном потоке (справедливо и для процессов, так как процесс имеет минимум 1 поток). При этом каждый поток за время своей жизни (которое в идеальных условиях совпадает со временем жизни всего uwsgi приложения) обрабатывает множество HTTP-запросов, сохраняя свое состояние (т.е. значения переменных уровня модулей) от запроса к запросу. В этом заключается чуть ли не основное отличие от модели обработки HTTP-запросов в PHP, где каждый запрос приходит новое только что проинициализированное окружение и загрузку приложения необходимо выполнять каждый раз заново.

    Типичным подходом в крупных web-приложениях на PHP является использование Dependency Injection Container для управления инициализацией и доступом к уровню сервисов приложения. Наглядным примером является Pimple . На каждый HTTP-запрос первым делом выполняется код инициализации, регистрирующий все доступные сервисы в контейнере. Далее по мере необходимости осуществляется доступ к объектом сервисов (lazy) в контроллерах. Каждый сервис может зависеть от других сервисов, зависимости разрешаются опять же через контейнер в коде инициализации сервиса-агрегата.

    // Определяем сервисы $container["session_storage"] = function ($c) { return new SessionStorage("SESSION_ID"); }; $container["session"] = function ($c) { return new Session($c["session_storage"]); }; // Используем сервисы class MyController { public function __construct() { // get the session object $this->session = $container["session"]; // "тестриуемость" страдает, но не суть } }
    Благодаря контейнеру, можно обеспечить единовременное создание объектов и возвращение уже готовых объектов на каждое последующее обращение к сервису (если необходимо). Но эта магия работает только в рамках одного HTTP-запроса, поэтому сервисы можно без проблем инициализировать специфичными для запроса значениями. Такие значения зачастую - это текущий авторизованный пользователь, сессия текущего пользователя, собственно HTTP-запрос и пр. В конце запроса сервисы все равно будут разрушены, а в начале обработки следующего запроса - созданы и проинициализированы новые. К тому же можно практически не беспокоиться об утечках памяти, если обработка одного HTTP-запроса умещается в отведенные для скрипта лимиты, так как создание сервисов происходит по требованию (lazy) и на один запрос каждый необходимый сервис скорее всего будет создан только в единственном экземпляре.

    Теперь, принимая во внимание вышеописанную поточную модель Python, можно заметить, что использование аналогичного подхода в Python web-приложении не возможно без дополнительных усилий. Если контейнер будет являться переменной уровня модуля (что выглядит вполне логично), все сервисы, которые он содержит, не могут быть проинициализированы специфичными для текущего запроса значениями, так как сервис будет являться разделяемым ресурсом между несколькими потоками, выполяющими обработку нескольких HTTP-запросов псевдо-параллельно. На первый взгляд существует два способа справиться с этой проблемой - сделать объекты сервисов независимыми от текущего HTTP-запроса (зависимыми остануться вызовы методов сервисов, а стековые переменные, используемые в методах, не являются разделяемыми ресурсами) или же сделать контейнер - ресурсом потока, а не процесса (тогда каждый поток будет общаться только со своим независимым набором сервисов, а в один момент времени один поток может обрабатывать только один HTTP-запрос).

    Кажущийся плюс первого подхода - сервисы инициализируются только один раз за все время жизни uwsgi процесса. Возможна также экономия памяти (так как имеем только один набор сервисов на все потоки). С другой стороны обработка конкретного HTTP-запроса требует лишь какого-то (скорее всего небольшого) поднможества всех доступных сервисов. Если же приложение достаточно большое и обладает внушительным количеством сервисов, то после обработки определенного числа HTTP-запросов, подавляющее большинство сервисов окажется проинициализировнными и находящимися в памяти процесса. Выглядит так, что это может оказаться серьезной проблемой.

    Второй подход можно реализовать с использованием



    СХОЖИЕ СТАТЬИ