Изучаем Django

Smoothing The Curve

2010-06-07T00:57:00.008+04:00

Smoothing The Curve

Sean O'Connor February 11^th 2010

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

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

До выхода в свет версии Django 1.2 для ORM такая кривая имела аналогичный вид, за одним исключением: существенный скачок в конце. Этот скачок появлялся в связи с тем, что при необходимости создания нестандартного SQL-запроса требовалось выйти за пределы ORM. Чтобы использовать определённый функционал ORM, пользователю пришлось бы создавать его заново самостоятельно, хоть это и не является само по себе катастрофой. В версии Django 1.2 добавлен метод Model.objects.raw (), который решает эту проблему и, таким образом, сглаживает эту кривую для ORM.

Старый способ

До выхода версии Django 1.2 при необходимости создать SQL запрос, нужно было написать нечто подобное:

from django.db import connection
from library.models import Author 

cursor = connection.cursor()
query = "SELECT * FROM library_author"
cursor.execute(query)
results = cursor.fetchall() 

authors = []
for result in results:
    author = Author(*result)
    authors.append(author)

Не то чтобы это было совсем ужасно, но здесь мы теряем доступ к функционалу ORM во всём, что не касается создания SQL запросов. В частности, недоступна автоматическая трансформация результатов запроса в экземпляр модели. В меру трудоёмкие способы восстановить утраченную функциональность, конечно, существуют, но фактически это будет изобретением велосипеда.

Новый способ

В версии Django 1.2 для создания прямого SQL запроса нужно написать следующее:

from library.models import Author 

query = "SELECT * FROM library_author"
authors = Author.objects.raw(query)

authors здесь будет экземпляром RawQuerySet. RawQuerySet во многом похож на QuerySet. В частности, сходство в том, что это — итерируемый объект, который возвращает экземпляр модели из результатов запроса с каждой итерацией. Отличие его от QuerySet состоит в том, что его нельзя встроить в цепочку. Но здесь это и не важно, поскольку запросы больше не формируются автоматически.

Как и при использовании БД курсора мы можем передать набор параметров запроса, Django заботливо их экранирует.

query = "SELECT * FROM library_author WHERE first_name = %s"
params = ('bob',)
authors = Author.objects.raw(query, params)

Так это же здорово! Код SQL защищён от атак, у нас экземпляр модели, который мы хотели, и никакого изобретения велосипеда.

«Но и это ещё не всё!»

Как и большинство инструментов Django, метод raw () оставляет пространство для использования дополнительных функций в неудобных ситуациях или для особо сложных запросов:

Независимый порядок полей

Для метода Model.objects.raw () неважно, в каком порядке возвращаются поля по запросу. Единственное, что важно — соответствуют ли имена полей запроса полям в модели.

# All of these queries will work the same
Author.objects.raw("SELECT * FROM library_author")
Author.objects.raw("SELECT id, first_name, last_name FROM library_author")
Author.objects.raw("SELECT last_name, id, first_name FROM library_author")

Аннотации

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

>>> authors = Author.objects.raw("SELECT *, age(birth_date) as age FROM library_authors")
>>> for author in authors:
...     print "%s is %s." % (author.first_name, author.age)
John is 37.
Jane is 42.
...

Определения соотношения между полями модели и запроса

Если по какой-либо причине не удаётся точно сопоставить имена поля запросов и имена поля модели, метод Model.objects.raw () предоставляет возможность указать его вручную.

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

field_map = {'first': 'first_name', 'last': 'last_name'}
    query = 'SELECT id, first_name AS first, last_name as last FROM library_author'
    authors = Author.objects.raw(query, translations=field_map)

Отложенные поля

Те поля, которые предполагаются в модели, но не возвращаются запросом, отмечаются как отложенные. Они будут заполнены только при запросе к полю экземпляра модели. Это полезно в тех случаях, когда данные запрашиваются не из «реальной» таблицы для модели, или когда сами таблицы достаточно большие. Здесь надо иметь в виду, что первичный ключ не может быть отложен и должен быть возвращён всеми запросами. Если запрос не возвращает первичный ключ, будет вызвано исключение InvalidQuery.

Ограничения

На действия метода raw () накладываются некоторые ограничения. Самое существенное из них заключается в том, что метод raw () поддерживает только SELECT запросы. При попытке использовать любой другой тип запроса, будет вызвано исключение InvalidQuery. Первоначально это было сделано с целью защиты, но отчасти это сделано так и потому что нет смысла возвращать экземпляр модели для чего-либо ещё кроме запроса типа SELECT. Изменение данных с помощью прямого SQL — это последнее, что стоит делать с помощью Django. Чтобы не провоцировать эти действия, мы ни в коем случае не хотим делать их удобнее для пользователя. Если вам требуется использовать именно прямые запросы SQL кроме запроса типа SELECT, у вас всегда остаётся возможность создать курсор БД и работать оттуда.

Вот и всё

Ну вот и всё. В версии Django 1.2 существенно упрощена работа с SQL запросами там, где это необходимо. Кривая, о которой мы говорили выше, имеет гораздо более гладкий вид. Официальную документацию для этой функции можно найти в разделе, посвящённому SQL.

Шон О’Коннор — разработчик HUGE и один из партнёров организаторов сайта для группы пользователей Django NYC. В течение трёх предыдущих лет Шон работал над приложениями Django и последнее время внёс существенный вклад в базовые усовершенствования раздела прямых SQL запросов в Django 1.2. В свободное от разработки Django и HUGE время он пьёт пиво и играет в настольные игры. Найти в интернете его можно по адресу seanoc.com (http://seanoc.com/), его твиттер — @theSeanOC.

Оригинальная статья

Messages for the rest of us

2010-05-27T00:17:00.001+04:00

Messages for the rest of us

Jeff Croft February 10^th 2010

Эта статья описывает изменения механизма сообщений в Django. В Django 1.2 можно посылать сообщения не только зарегистрированным пользователям, но и анонимным. Полностью переработан API.

Статья уже переведена мои другом Дмитрием Медвинским:

http://habrahabr.ru/blogs/django/87473/

Дмитрий мой бывший коллега и просто замечательный человек, follow @justadeveloper!

Multiple database support

2010-05-22T21:20:00.006+04:00

Multiple database support

Alex Gaynor February 9^th 2010

Изначально Django предполагал работу только с одной базой данных (системное ограничение включающее такие вещи как группа настроек DATABASE_*). В течение всего этого времени явно ощущалась необходимость поддержки возможности работы с несколькими БД. В рамках работы над версией 1.2 в течение Google Summer of Code поддержка нескольких БД была включена в trunk. С этими новшествами связаны как целый ряд внутренних изменений, так и несколько удачных расширений для существующих интерфейсов работы с БД.

Интерфейс работы с несколькими БД

Наиболее заметное изменение в Django состоит в том, что, вместо того, чтобы писать настройки базы данных таким образом:

DATABASE_ENGINE = "postgresql_psycopg2"
DATABASE_NAME = "my_big_project"
DATABASE_USER = "mario"
DATABASE_PASSWORD = "princess_peach"

Вы пишете следующее:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql_psycopg2",
        "NAME": "my_big_project",
        "USER": "mario",
        "PASSWORD": "princess_peach",
    },

    "credentials": {
        "ENGINE": "django.db.backends.oracle",
        "NAME": "users",
    }
}

В конечном итоге все проекты должны будут быть переведены в такой вид, хотя старый формат будет поддерживаться в Django вплоть до версии 1.4. Единственный ключ в словаре DATABASES, имеющий критическое значение, это «default» — «по умолчанию». Если вы используете базу данных, вам необходимо определить базу данных «default».

Теперь, когда вы сообщили Django о всех своих базах данных, надо найти способ сообщить Django о том, как их использовать. Первым изменением интерфейса в этой области является метод using(). using() принимает единственный параметр имя БД (имена БД служат ключами словаря DATABASES), и привязывает QuerySet к этой базе данных. Как и любое другое средство класса QuerySet, он может быть при необходимости поставлен в цепочку (как, например, метод order_by(), обновляющий результаты первого запроса при повторном запросе). По сути, это даёт вам возможность полностью контролировать, откуда будут читаться данные (а при ловком использовании методов create(), delete() и update() даёт даже возможность контролировать запись):

>>>User.objects.filter(username__startswith="admin").using("credentials")

Новые методы работы с данными класса QuerySet delete() и save() принимают дополнительный аргумент using, в который передаётся, опять же, имя БД.

Кроме того, появляется новый метод класса Managers, db_manager(), который тоже принимает имя БД. Его функция по сути близка функции метода using(). Основное различие заключается в следующем: вместо того, чтобы возвращать QuerySet, он возвращает новый Manager. Сценарий его использования делает возможным связать его в цепочку с теми методами класса Managers, которые не возвращают QuerySet (например, такими как create_user() класса UserManager).

Маршрутизаторы БД

Используя все эти методы, вы получаете возможность реализовать любую систему, использующую несколько баз данных. В том числе master-slave replication, partitioning и sharding. Однако, это не обязательно будет удобно. Вам придётся часто использовать в коде запросы к методу using(), что не лучшим образом совместимо с принципом реиспользуемых приложений Django (именно по этой причине опция using была удалена из класса модели Meta). Кроме того, в некоторых случаях класс QuerySet не полностью определён. Так, например, для получения доступа к данным класса User метод my_obj.user неявно создаст QuerySet, но методу using() будет некуда отправить запрос. Этим и было обусловлено появление концепции «маршрутизатора БД». Маршрутизаторы БД получают всю информацию о запросе, который вы хотите выполнить, и определяют, какую базу необходимо обратиться. Маршрутизаторы задаются в файле настроек в виде списка DATABASE_ROUTERS:

DATABASE_ROUTERS = [
     "path.to.AuthRouter",
     "path.to.MasterSlaveRouter",
 ]

DATABASE_ROUTERS задаётся списком, поскольку маршрутизатор на любой стадии может вернуть значение None и тогда Django перейдет к следующему маршрутизатору из списка. Маршрутизаторы могу определять следующие методы:

db_for_read
db_for_write
allow_relation
allow_syncdb

Первые два метода очевидны, они возвращают имя БД, по отношению к которой выполняется запрос. Метод allow_relation призван контролировать разумность запросов. Django не позволит вам создать заведомо некорректные связи между БД. То есть, если вы попытаетесь создать взаимосвязь между двумя структурами данных из разных БД (для ForeignKey или для ManyToManyField), с помощью данного метода Django запросит необходимое подтверждение. И последний метод allow_syncdb позволяет определить, в какой из баз данных будет создана конкретная модель.

В документации Django по работе с несколькими БД, как всегда, приведена масса практических примеров. В том числе приведены примеры, описывающие, как начать применять распространённые паттерны с маршрутизаторами баз данных. Поддержка нескольких баз данных дает огромные преимущества и значительно расширяет области применения Django.

Алекс Гейнор — студент второго года обучения политехнического института Renesselear по специальности вычислительная техника, работает в качестве веб-разработчика в Eldarion. Работает с Django около двух лет, и примерно столько же активно участвует в его дальнейшей разработке. Кроме работы с Django, он вносит свой вклад в развитие таких проектов, как Pinax, django-debug-toolbar, а также запустил несколько собственных — как, например, django-filter, и django-taggit. Поклонник качественных программных интерфейсов, гибкого масштабирования и компиляторов.

Оригинал статьи | Все статьи

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

Если вам понравился перевод подписывайтесь на RSS, я планирую перевести всю серию статей.

Хотите сообщить об ошибке в статье? Обсудить или задать вопрос по работе с несколькими БД? Добро пожаловать в комментарии.

Welcome to Django Advent

2010-05-19T01:57:00.008+04:00

Welcome to Django-Advent

Jacob Kaplan-Moss February 8^th 2010

Релиз Django 1.2 невероятно меня воодушевил. Оглядываясь назад, я могу сказать, что было несколько моментов, которые оказались ключевыми как для самого проекта Django, так и для общества в целом. Слияние ветки «magic-removal» и последующий релиз 0.96 был первым таким моментом: мы выпустили улучшенный Django и наше сообщество начало развиваться огромными скачками. Релиз Django 1.0 стал следующим ключевым моментом. Метка 1.0 гордо символизировала наш профессионализм и зрелость проекта.

И я абсолютно уверен, что версия 1.2 станет очередной ключевой точкой проекта.

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

В течение нескольких следующих недель мы будем писать статьи, где более подробно и глубоко обсуждаются новые особенности проекта; многие из статей написаны теми, кто разрабатывал и вводил эти особенности. И чтобы не отбирать у них хлеб, я постараюсь рассмотреть их в общем, и показать как они закладывают основу для Django 1.3, 1.4 и выше.

Поддержка множественных соединений с базами данных это «киллер фича» Django 1.2. Добавление функции такого рода — интересная задача: существуют разногласие между нуждами начинающих и разработчиков ненагруженных приложений — которые более всего ценят простоту и удобство в использовании — и возрастающего числа разработчиков высоконагруженных приложений, которым необходимо больше контроля и гибкости, то есть большей сложности фремворка.

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

В новой поддержке множественных соединений с базами данных Django я вижу, что мы весьма близко подобрались к границе. Я очень горжусь той работой, которую мы сделали, балансируя между конкурирующими потребностями: начать пользоваться Django 1.2 просто, как всегда, но мы весьма расширили горизонты Django. И я надеюсь, что мы сможем нащупать баланс между мирами.

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

Многие из новичков попали к нам через Google’s Summer of Code 2009. В том году мы приняли 6 проектов:

поддержка множественных соединений с базами данных (Alex Gaynor)
улучшения HTTP и WSGI (Chris Cahoon)
улучшенние локализации (Marc Garcia)
валидация моделей (Honza Král)
дополнения к тестовому фреймворку (Kevin Kubasic)
улучшения администрировного интерфейса (Zain Memon).

Программа имела потрясающий успех: все проекты произвели хороший, работающий код. Часть его вошла в версию 1.2 часть продолжит свой путь в выпуске 1.3. Многие из этих проектов были воодушевлены долгим ожиданием новых функций, а работа, сделанная в течение Summer of Code оказалась как раз тем, что было нам нужно для их реализации.

Мы также добавили пару новых разработчиков — Jannis Leidel и James Tauber — и я готов спорить, что мы увидим еще ребят, которые будут задействованы в проекте до финального релиза.

Кстати, когда же он? (Django 1.2 вышел 17 мая 2010) прим. переводчика

Запланированная дата релиза — 9 марта 2010 года. И мы стоим на пути к тому, что выпуск осуществится вовремя… но мы никогда не сделали бы этого без Вашей помощи!

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

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

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

Мы также проводим спринт для разработчиков по Django 1.2 на PyCon US 2010. В течении четырех дней спринта (22—25 февраля) мы будем рады, если вы присоединитесь к нам лично или виртуально по IRC (#django-dev на irc.freenode.net) или на http://groups.google.com/group/django-developers

Я надеюсь, что вам понравятся остальные статьи и что в конце концов вы будете столь же впечатлены выходом Django 1.2, как и я!

Статья на Английском

В честь выхода Django 1.2 решил перевести статьи с замечательного сайта Django Advent

Сейчас на сайте опубликовано 20 статей, и каждая из них рассказывает нам о новой возможности Django. Поверьте, там есть на что посмотреть.

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

List clustering

2010-03-09T12:10:00.001+03:00

Today I will tell you about just one line of code:

zip(*[a.__iter__()]*3)

So, if you know, how it works, you can skip to the comments right now. :)

This statement may look short and simple but it's actually very interesting and, sometimes, useful Python construction. In a job interviews we ask people to tell how does it work. If a person gets along with it, well, this is a good sign.

Here is the example of what it does:

>>> a = [1,2,3,4,5,6,7,8,10]
>>> zip(*[a.__iter__()]*3)
[(1, 2, 3), (4, 5, 6), (7, 8, 10)]

Lets look at it piecemeal.

iter()

Returns iterator object for a list (or tuple or any other iterable object).

This method is used by the interpreter when he encounters a list in, for example, a for loop.

The iterator object by itself has a next() method, which returns list items one by one.

[]*3

Multiplication of a list creates a new list repeating given amount of times the items from source list:

>>> [1,2,3] * 3
[1, 2, 3, 1, 2, 3, 1, 2, 3]

Important thing here: all identifiers in Python are references. It means that [a.__iter__()]*3 gives us a list of three references on the same iterator object.

A little example (note the address of listiterator object is the same):

>>> iters = [a.__iter__()]*3
>>> print iters
[<listiterator object at 0x85db0>, <listiterator object at 0x85db0>, <listiterator object at 0x85db0>]
>>> (iters[0].next(), iters[1].next(), iters[2].next())
(1, 2, 3)

*

Takes an iterable object and passes it's members to a function as non-keyword arguments.

This is one of my favourite Python features. The following lines are equivalent:

my_func(*[1,2,3])
my_func(1,2,3)

zip

zip returns a list of tuples, where the i-th tuple consists of i-th member of each function argument. For example:

>>> zip((1,2), (3,4), (4,5))
[(1, 3, 4), (2, 4, 5)]

Official Python documentation declares:

The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using zip(*[iter(s)]*n).

You may have noticed the construction we are trying to understand here. So, this isn't some Perl one-liner, but an official Python feature.

Use the power of Python,
and may the Force be with you.

Кластеризация списка (List clustering)

2010-03-08T12:51:00.010+03:00

И снова здравствуйте :)

Давненько я не писал, и с того времени произошло много хороших вещей:

Вышла бета Django 1.2, в ней огромное количество позитивных изменений. Такое чувство, что мне не хватало каждого из них. Взять хотя бы smart if tag, object-level permissions, session messages и улучшения интернационализации (теперь дата форматируется согласно текущей локали по умолчанию).

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

Следите за обновлениями.

На работе мы стали использовать pip, очень удобная вещь на мой взгляд.

Вот, например, файл зависимостей из одного проекта:

Django==1.1
south==0.6.2
django-debug-toolbar==0.8.1
django-extensions==0.4.1
django-notification==0.1.2 #0.1.3-4 has a bug in lockfile.py
django-messages==0.4.2
django-sphinx==2.1.2
supercaptcha==0.1.1
-e svn+http://django-session-messages.googlecode.com/svn/trunk@5#egg=django-session-messages
http://github.com/sunlightlabs/django-blogdor/zipball/65adc834b3255e82ea7eb3efa484af49a7438f62
django-markupfield==0.3.0 #blogdor use
el-django-compress==1.0.3 # problems with installing original django-compress
sorl-thumbnail==3.2.5

# apps
--requirement=apps/facebook_login/libs.txt
--requirement=apps/twitter_login/libs.txt
--requirement=apps/payment/libs.txt

Перешли с deseb на South.

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

На South я возлагаю большие надежды. Он использует другой подход, и этот подход действительно работает! После периода "привыкания" команды, можно сказать, что он нам подходит. Любой разработчик запускает migrate и, о чудо, база данных станет актуальной. Точно так же можно без опаски запускать его на сервере.

Подробнее об этом расскажу в следующем посте.
27 марта в Санкт-Петербурге, я буду выступать с докладом на конференции ZFConf 2010, посвященной PHP Zend Framework, приходите, кому интересно :)

Кластеризация списка (List clustering)

Сегодня я буду рассказывать всего лишь об одной строчке кода:

zip(*[iter(a)]*3)

Если вы знаете как она работает, можете дальше не читать ;)

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

Полный пример работы кластеризации:

>>> a = [1,2,3,4,5,6,7,8,10]
>>> zip(*[iter(a)]*3)
[(1, 2, 3), (4, 5, 6), (7, 8, 10)]

Разберем эту конструкцию по частям.

iter()

Возвращает объект-итератор для списка (кортежа или любого другого итерируемого элемента).

Этот метод используется интерпретатором, когда список попадает, например, в цикл for.

Сам объект итератор имеет метод next(), который один за другим возвращает элементы списка.

[]*3

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

>>> [1,2,3] * 3
[1, 2, 3, 1, 2, 3, 1, 2, 3]

Здесь важный момент: все идентификаторы в Python — это ссылки. То есть конструкция [iter(a)]*3 даст нам список из трех ссылок на один и тот же итератор списка. Небольшой пример:

>>> iters = [iter(a)]*3
>>> print iters
[<listiterator object at 0x85db0>, <listiterator object at 0x85db0>, <listiterator object at 0x85db0>]
>>> (iters[0].next(), iters[1].next(), iters[2].next())
(1, 2, 3)

*

Превращает итерируемый объект в список неименованных аргументов функции.

Одна из моих любимых возможностей Python. Следующие конструкции эквивалентны:

my_func(*[1,2,3])
my_func(1,2,3)

zip

zip возращает список кортежей, где i-тый кортеж состоит из i-тых элементов каждого из агрументов функции. Например:

>>> zip((1,2), (3,4), (4,5))
[(1, 3, 4), (2, 4, 5)]

В официальной документации к функции zip описана последняя особенность, благодаря которой кластеризация работает.

The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using zip(*[iter(s)]*n).

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

А какие интересные конструкции Python знаете вы?

Покрытометр (Django coverage)

2009-06-07T22:34:00.007+04:00

В рамках программы по улучшению качества кода начали писать на работе модульные тесты.

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

В этой уверенности кроется одна проблема, я не знаю какая часть кода покрыта тестами. Так как нам еще далеко до TDD, тесты проверяют лишь некоторые функции.

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

С какой вероятностью рефакторинг не добавил ошибок.
Над тестами к каким модулям стоит поработать для более равномерного покрытия.

Сказано — сделано. Для Python есть замечательная библиотека coverage, которая умеет определять степень покрытия кода.

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

Итак, coverage умеет высчитывать степень покрытия кода и строить изумительные html-отчеты, осталось немного — подружить ее с Django.

Для себя я выбрал следующий вариант. Обертка для стандратного test runner, которая по окончании работы генерирует html-отчет. На мой взгляд, достаточно удобно. Одна команда:

./manage.py test

и после запуска тестов у нас уже есть красивые отчеты, которые можно показать коллегам или начальству

Перейдем к самому интересному, к коду обертки, она требует совсем немного настроек в settings.py

#переопределиние стандартного test runner на наш
TEST_RUNNER = "core.test.coverage_runner.run_tests"
#путь к сгенерированным отчетам
COVERAGE_REPORT_PATH = os.path.join(workdir, 'coverage_report')

и кода в файле coverage_runner.py

""" 
Test runner with code coverage.
Falls back to django simple runner if coverage-lib not installed 
"""
import os

from django.test import simple
from django.conf import settings


#попытка импорта coverage библиотеки
try:
    from coverage import coverage as Coverage
except ImportError:
#если она не установлена, просто запустим стандартный обработчик
    run_tests = simple.run_tests 
else:
#если установлена примемся за построение отчета
    coverage = Coverage()
    def run_tests(test_labels, verbosity=1, interactive=True, extra_tests=[]):

# часть непосредственно отвечающая за получение данных о покрытии (включить сбор; выполнить тесты; выключить сбор)
        coverage.start()
        test_results = simple.run_tests(test_labels, verbosity, interactive, extra_tests)
        coverage.stop()

# Как известно, manage.py test может не все тесты, а только из определенных приложений
# немного не логично, что в этом случае покрытие будет определено для всего кода в проекте
# и для не ваших приложений и для библиотек.
# Следующий код берет имена приложений для тестирования из test_labels, определяет все модули
# входящие в их состав и передает список для построения отчета.
# Это очень удобно, мы тестируем только свой код и получаем только его покрытие.
        coverage_modules = []
        for app in test_labels:
            try:
                module = __import__(app, globals(), locals(), [''])
            except ImportError:
# Эта ситуация возникает в случае если тестирование ограничено одним TestCase, либо модуль недоступен
# В обоих случая нам не нужен отчет о покрытии.
                coverage_modules = None
                break
            if module:
                base_path = os.path.join(os.path.split(module.__file__)[0], "")
# Ищем внутри приложения непустые .py файлы
                for root, dirs, files in os.walk(base_path):
                    for fname in files:
                        if fname.endswith(".py") and os.path.getsize(os.path.join(root, fname)) > 1:
                            try:
                                mname = os.path.join(app, os.path.join(root, fname).replace(base_path, "")) 
                                coverage_modules.append(mname)
                            except ImportError:
                                pass #do nothing
        
# Строим html-отчет        
        if coverage_modules or not test_labels:
            coverage.html_report(coverage_modules, directory=settings.COVERAGE_REPORT_PATH)
                    
        return test_results

Для успешного использования coverage runner необходимо:

На выходе получаются красивые картинки. Общий отчет , отчет покрытия одного файла .

С радостью выслушаю замечания, мысли и истории "как у нас" по модульному тестированию и TDD в комментариях.

Еще предлагаю померяться в комментариях степенью покрытия кода. У нас — 49%.

Тайна замыкания

2009-05-25T21:41:00.005+04:00

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

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

Что такое декоратор?

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

Примеры декораторов из Django:

login_required: при обращении анонимного пользователя к декорированому view, перенаправляет его на страницу логина.
transaction.commit_on_success: выполняет все запросы из декорируемой функции к БД в одной транзакции и коммитит ее при успешном завершении.
cache_page(sec): кеширует результат выполнения view на sec секунд.

Два способа применения декоратора:

@login_required
def my_view(request):
 ...

def my_view(request):
 ...
my_view = login_required(my_view) #python 2.3

Получение id пользователя не вызывает проблем — request.user. А вот с получением имени функции не так все просто. Вот шаблон декоратора:


def decorator(function):
    def actual_decorator(request, *args, **kwargs):
        pass
    return actual_decorator

То есть, мы имеем указатель на декорируемую функцию function, и можно получить ее имя через function.func_name. Но тут возникает проблема, к функции часто применяется последовательность декораторов, например:


@limit_rate_request
@login_required
def my_view(request):
    ...

В этой ситуации function будет ссылаться на декоратор login_required и имя декорируемой функции мы получить не можем.

Что такое замыкание?

Это внутренняя функция, содержащая ссылки на локальные переменные внешней функции.

Например:


def func1():
    closure = 1
    def func2():
        print closure

В этом примере переменная closure замкнута в функции func2.

Так как на login_required замкнут указатель на декорируемую функцию, можно попробовать получить ее значение. У функции в питоне существует параметр func_closure — все замкнутые на функцию переменную. Но, к сожалению, их значения представлены классом cell и получить значение напрямую нельзя.

На помощь приходит Решение :)


def get_cell_value(cell):
 # функция, которая возращает функцию, которая в свою очередь вернет замкнутую на нее переменную
    def make_closure_that_returns_value(use_this_value):
        def closure_that_returns_value():
            return use_this_value
        return closure_that_returns_value
    # получаем экземпляр функции с замыканием с параметром 0
    dummy_function = make_closure_that_returns_value(0)
    # получаем байт-код этой функции
    dummy_function_code = dummy_function.func_code
    # создаем новый экземпляр функции вместо старой замкнутой переменной используем наш cell
    our_function = new.function(dummy_function_code, {}, None, None, (cell,))
    # вызываем функцию, и она возвращает значение нашей замкнутой переменной из cell
    value_from_cell = our_function()
    return value_from_cell

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

Таким образом, после первого запроса View в кеше будет установлена переменная PREFIX_USER_ID_FUNCTION_NAME, пока повторный запуск запрещен эта переменная хранится в кеше, как только таймаут вышел, кеш «протухает» и пользователь снова может сделать запрос.

Полный код декоратора:


def get_cell_value(cell):
    def make_closure_that_returns_value(use_this_value):
        def closure_that_returns_value():
            return use_this_value
        return closure_that_returns_value
    dummy_function = make_closure_that_returns_value(0)
    dummy_function_code = dummy_function.func_code
    our_function = types.FunctionType(dummy_function_code, {}, None, None, (cell,))    
    value_from_cell = our_function()
    return value_from_cell


def get_decorated_function(function):
    """ Returns actual decorated function in decorators stack """
    while function.func_closure is not None:
        function = get_cell_value(function.func_closure[0])
    return function
 
class limit_request_rate(object):
    """
    Decorator for view that limit request rate for view for concrete user.
    Anonymous users not limited. 
    @todo: differentiate anonymous users by IP
    """    
    CACHE_VAR_PREFIX = "limit_request_rate_"
    
    def __init__(self, timeout = None):
        self.timeout = timeout or settings.DEFAULT_REQUEST_TIMEOUT
    
    def __call__(self, function):        
        def actual_decorator(request, *args, **kwargs):
            if request.user.is_authenticated():                
                dec_func = get_decorated_function(function)
                cache_key = self.CACHE_VAR_PREFIX + str(request.user.id) + dec_func
.func_name + dec_func.func_code.co_filename
                if not cache.get(cache_key):
                    cache.set(cache_key, 1, self.timeout)
                    return function(request, *args, **kwargs)
                else:
                    return HttpResponseServiceUnavailable()            
            return function(request, *args, **kwargs)
        return actual_decorator

up: deprecated new.function заменен на Types.FunctionType

Оставьте комментарий, если вам есть что добавить, вы нашли ошибку в коде или что-то осталось непонятным.

Система развертывания (deploy system)

2009-03-24T08:37:00.007+03:00

Как я и обещал в предыдущей серии, посвящаю этот пост нашей системе развертывания.

Система самописная, достаточно тесно связана с процессом разработки и реализована при помощи sh-скрипта.

Общая схема

На рисунке приведена немного сумбурная схема процесса развертывания.

Разработка ведется с использованием SVN установленным на локальном сервере, там же расположен и локальный сервер MySQL. MySQL используется всеми при разработке, структура создается через initdb. Начальные данные в обязательном порядке (скоро узнаете почему) сохраняются либо в fixtures, либо в init.sql, а в случае прав пользователей создается команда manage.py.

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

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

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

Когда проект готов для тестирования, менеджер проекта запускает (по ssh;) развертывание на TEST он же помечен цифрой 2 на схеме. Структура база данных переносится из DEV версии.

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

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

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

Процесс деплоя на TEST выполняется итеративно, пока не будут исправлены все обнаруженные ошибки. И тогда наступает час X, менеджер проекта достает большую красную кнопку и запускает развертывание на PROD версию.

PROD версия проекта — инструмент пользователей. Используется интернет пользователями по назначению. (например для связи бизнеса и СМИ).

Обновляется по запросу, после окончания тестирования.

Публичная версия обновляется исключительно с TEST версии, копированием файлов и структуры базы. Это с одной стороны дает гарантию что мы запустим именно тот код который был оттестирован, с другой подразумевает что любые изменения должны быть проверены (задеплоиться с DEV или репозитория нельзя).

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

Конфигурация системы

Система планировалась более-менее универсальной, поэтому у каждого проекта есть опции развертывания, которые должны храниться в файле deploy/params.sh. Основные параметры:

Параметры SVN репозитория, для скачивания и обновления исходного кода.
Параметры MySQL сервера, который используется для переноса изменений структуры на DEV.
Имя конечного конфигурационного файла, который формируется из шаблона для каждой версии проекта.
Путь к media и загружаемым файлам пользователя.
Базовые порты FCGI и SPHINX.
Команда выполняемая сразу после деплоя (обычно команда инициализации прав пользователей).

Параметры представлены как переменные и добавляются с помощью включения скрипта.

MySQL

С базой при деплое все достаточно просто, если её не существует, скрипт запускает создание базы manage.py initdb, Django загружает fixtures, скрипт запускает init.sql и в конце выполняет прописанную в конфиге команду. Огромное разнообразие методов начальной загрузки данных удовлетворяет любые даже самые сложные случаи.

Например, в свое время мы столкнулись со сложностью распределения прав пользователей по группам. На уровне fixtures или init.sql ну никак не получалось этого сделать, из-за того что на разных версиях проекта, созданные initdb права, имеют разные id. В итоге и появилась команда выполняемая в конце развертывания, которая используя стандартные методы Django, формирует необходимые группы пользоватей и распределяет права доступа.

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

Если база данных уже создана, то при развертывании переносится только структура с помощью mysqldiff. Этот скрипт делает экспорт структуры двух баз данных (откуда и куда переносим), сравнивает эти данные и формирует sql скрипт для обновления целевой базы. Скрипт уже стандартными средствами СУБД применяется к базе. Причем при деплое на PROD, скрипт просматривается вручную, дабы в случае сбоя не удалить пользовательские данные.

Конфигурационные файлы

Одна из моих любимых функций нашей системы — генерация конфигурационных файлов.

Конфиг разработчиков хранится в отдельном файле base_settings.py а в стандартном settings.py всего одна строчка включения базовых настроек from base_settings.py import *.

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

Поведение специфичное для конкретной версии (имена баз данных, например, у всех разные) поддерживается макро-язык суть которого в замене конструкции {имя версии: значение} на значение. Допустим строка

DATABASE_NAME={dev:eshtab_dev}{test:eshtab_test}{prod:eshtab}

при развертывании на TEST будет исправлена на DATABASE_NAME = eshtab_test.

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

{instance}: DEV, TEST или PROD — версия системы.
{dbname}: имя базы данных.
{sitepath}: путь к файлам проекта.
{domain}: базовый адрес версии проектам (например dev.eshtab.ru).
{fcgi_port}: FCGI порт, используется как Django так и NGINX.
{sphinx_port}: порт поискового движка, используемого на наших проектах.
{media_path}: путь к статическим файлам.

Подстановки изумительны с точки зрения DRY, они используются как в Django так и в конфигурационных файлах SPHINX, NGINX, так и в скриптах запуска.

Макро-замены и подстановки осуществляются потоковым текстовым редактором sed. После замен settings.py заменяется шаблоном.

SPHINX, NGINX

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

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

{dev:#}{test:#}    server {
{dev:#}{test:#}        listen       80;
{dev:#}{test:#}        server_name .{domain};
{dev:#}{test:#}        rewrite ^/(.*) http://www.{domain}/$1 permanent;
{dev:#}{test:#}    
}

Как вы наверно догадались на DEV и TEST эти строки будут закомментированы, а на PROD веб-сервер будет переадресовывать запросы с domain на www.domain из эстетических соображений.

На правах заключения

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

Полезные штуки: deseb

2009-02-08T16:49:00.004+03:00

Здравствуйте, мои дорогие друзья.

Что-то я давно не писал, хотя с последнего раза много интересного произошло:

Вышел Django 1.0, и даже Django 1.0.1.
На работе светлая сторона силы взяла свое и мы написали два проекта на Django

scrum

РосБизнесТура

Сегодня я расскажу о замечательной утилите для Django — deseb.

Deseb добавляет к manage.py всего одну команду evolvedb, эта команда позволяет сгенерировать новую схему базы данных из моделей не теряя данных уже находящихся в базе

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

Рассмотрим пример использования команды evolvedb. Для начала нужно установить deseb:

Перейдем в директорию с проектом coblog.

Получим исходные коды deseb

svn checkout http://deseb.googlecode.com/svn/trunk/src/deseb

И добавим import deseb в начало файла setting.py.

Для примера исправим одну из ошибок в нашем проекте, непозволяющую создавать комментарии без parent и еще пару мелочей. В файле default/models.py заменим

posted = models.DateTimeField()

в модели Post на

posted = models.DateTimeField(blank=True, null=True)

В модели Comment строчку

parent = models.ForeignKey('self')

на

parent = models.ForeignKey('self', null=True, blank=True)

И строчку

__rate = models.IntegerField()

в той же модели на

__rate = models.IntegerField(default=0)

Теперь для изменения базы данных и пригодится команда evolvedb. Запустим ее:

python manage.py evolvedb

… ничего не происходит. Оказалось, что evolvedb не срабатывает на изменение параметров внешних ключей.

Придется немного доработать deseb для того чтобы он воспринимал эти изменения. В файле deseb/schema_evolution.py заменим строчку

if data_types.has_key(data_type):

на строчку

if not f.db_type() is None:

и чудесным образом evolvedb предложит внести изменения в базу.

Я не уверен, что внесенные изменения deseb оправданы и ничего не сломается при работе с другими БД, кто может что сказать по этому поводу?

Вот такой полезный иструмент deseb, надеюсь он будет вам полезен.

Беспрецедентная акция

Оставьте комментарий о теме которую вы бы хотели узнать в следующий раз. И я напишу о ней.

Админка

2008-07-20T19:30:00.014+04:00

Не успел я написать про административный интерфейс в Django, как произошло радостное событие — он сильно изменился, став еще лучше. Поэтому не вижу смысла описывать старую функциональность и расскажу про новый вариант. Для использования newforms-admin необходимо:

Обновить Django, выполнив следующие команды в директории с рабочей копией (полученной при помощи svn checkout).
```
svn up
python setup.py install
```
Удалить все блоки class Admin: pass из файла default/models.py

Что это

Админка — это автоматически генерируемое средство для управления моделями вашего приложения. Она обладает большими возможностями по настройке под нужды конкретного приложения. В нашем случаем мы могли бы использовать админку для:

Модерации постов и комментариев
Создании и удалении пользователей, причем при удалении автоматически удаляются все зависимые от пользователя объекты: профайл, сообщения и комментарии.
Блокирования пользователей
Просмотра статистики зарегистрированных пользователей, количества постов и комментариев.

Административный интерфейс в Django не только является инструментом разработчика, но и полностью готово для использования при эксплуатации сайтов. В своем php-проекте на работе нам пришлось писать админку самим, причем почти все существующие и планируемые функции повторяют функциональность Django-админки.

Объекты ModelAdmin

Админка описывается в файле admin.py при помощи специальных объектов ModelAdmin, различные поля этих объектов позволяют управлять функциональностью. Например создадим ModelAdmin для записи в блоге:

class PostAdmin(admin.ModelAdmin):
    pass
admin.site.register(Post, PostAdmin)

последняя строка говорит Django о том, что мы хотим использовать класс PostAdmin для описания админки класса Post. Сгенерированный интерфейс будет выглядеть так: Немного приукрасим его, сгрупировав поля:

class PostAdmin(admin.ModelAdmin):
    fieldsets = (
        (None, {
            'fields': ('blog', 'poster', 'posted')
        }),
        ('Содержимое', {
            'fields': ('draft', 'caption', 'content')
        })
    )

Для тэгов к записи можно было объявить такие же объекты, но они появлялись бы в отдельном списке и редактировались по одному, что, согласитесь, не очень удобно. Встроим редактирование тегов в редактирование поста, при помощи специального класса InlineModelAdmin:

class TagInline(admin.TabularInline):
    model = Tag

class PostAdmin(admin.ModelAdmin):
    ...
    inlines = [
        TagInline,
    ]

Вот такой блок добавится к редактированию поста в результате: Файл admin.py для всех моделей:

from coblog.default.models import *
from django.contrib.auth.models import User
from django.contrib.auth.admin import UserAdmin
from django.contrib import admin

class BlogAdmin(admin.ModelAdmin):
    pass

class TagInline(admin.TabularInline):
    model = Tag

class CommentInline(admin.StackedInline):
    model = Comment
    fieldsets = (
        (None, {
            'fields': (('user', 'parent'), 'content'),
            'classes': ['collapse']
        }),
    )


class PostAdmin(admin.ModelAdmin):
    fieldsets = (
        (None, {
            'fields': ('blog', 'poster', 'posted')
        }),
        ('Содержимое', {
           'fields': (('caption','draft'), 'content')
        })
    )
    inlines = [
       TagInline,
       CommentInline
    ]

class ProfileInline(admin.StackedInline):
    model = Profile
    extra = 0
    max_num = 1

#Расширим стандартный интерфейс редактирования пользователя нашим профайлом
class MyUserAdmin(UserAdmin):
    inlines = [
        ProfileInline
    ]

#перерегистрируем админку для пользователя
admin.site.unregister(User)
admin.site.register(User, MyUserAdmin)

admin.site.register(Blog, BlogAdmin)
admin.site.register(Post, PostAdmin)

Подлючение

Для активации админки исправим urls.py:

from django.conf.urls.defaults import *
from django.contrib import admin

#автоматическое подключение необходимых приложений
admin.autodiscover()

urlpatterns = patterns('',
  # Example:
  # (r'^coblog/', include('coblog.foo.urls')),

  # Uncomment this for admin:
  ('^admin/(.*)', admin.site.root),
)

Можете запустить сервер и посмотреть на результат:

python manage.py runserver

Запись DVD при помощи Django

2008-07-13T11:06:00.009+04:00

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

Недавно установил сервер с Azureus Web UI для скачивания фильмов. Но осталась одна проблема — запись DVD для просмотра на домашнем кинотеатре. Немного поискав так и не нашел веб-приложения для записи дисков, ну что ж, напишем сами. Основная идея скрипта — позволить пользователю выбрать директорию или файл на сервере и выполнить команду записи из пакета dvd+rw-tools:

growisofs -dvd-compat -Z <устройство> -R -J -pad "<путь к директории для записи>"

к фильмам выложенным без VIDEO_TS необходимо его добавить:

growisofs -dvd-compat -Z <устройство> -R -J -pad -graftpoints "/VIDEO_TS=<путь к директории для записи>"

Используемые возможности Django:

Человеко-понятные урлы
Шаблонный движок
MVC

неиспользуемые возможности (ORM, i18n, админка) нисколько не мешают, благодаря модульной архитектуре Django.

Библиотека записи

Начнем с библиотеки-обертки над growisofs. Она достаточно простая, объект Burner в конструкторе принимающий имя записывающего устройства, пытается определить версию growisofs и если ее нет вызывает исключение. В объекте метод burndvd с параметром path, используя subprocess.Popen пытается нарезать диск. Ошибки определяются чтением stderr и отражаются вызовом нескольких исключений.

# -*- coding: utf-8 -*-

import os, re, subprocess, types

class Burner:
 """Simple dvd burner class. Uses growisofs"""

 class MediaNotFoundException(Exception):
  pass
 class GrowisofsNotFoundException(Exception):
  pass
 class NotEnoughSpaceException(Exception):
  pass

 __device = None 
 __growisofs = 'growisofs'
 __videodir = 'VIDEO_TS'
 __version = None
 
 def __init__(self, device):
  self.__device = device
  #determine growisofs version
  try:
   popen = subprocess.Popen([self.__growisofs, '--help'], stdout = subprocess.PIPE)
  except OSError, (errno,strerror):
   raise self.GrowisofsNotFoundException((errno,strerror))
  popen.wait()
  str = popen.stdout.readline()
  if len(str) == 0:
   raise self.GrowisofsNotFoundException('no output procuced by growisofs --help')
  match = re.compile('version (\d.\d.\d)').search(str)
  if match == None:
   raise self.GrowisofsNotFoundException('version info not found')
  self.__version = match.group(1)

 def get_growisofs_version(self):
  return self.__version

 def burndvd(self, path):
  """
  burn file or directory from path variable on disk as video
  for dirs automatically determines VIDEO_TS exists inside, if not
  files will been writen to VIDEO_TS directory
  """
  #TODO split DVD9 to two DVD5
  #TODO parse percentages when burning
  if not os.path.exists(path):
   raise IOError('path not found')

  if os.path.isfile(path):
   burnpath = path
  elif os.path.isdir(path):
   videodir = filter(lambda arg:os.path.split(arg[0])[1] == self.__videodir, 
    os.walk(path))
   if len(videodir) == 0:
    burnpath = '/' + self.__videodir + '=' + path
   else:
    burnpath = path
  
  #start burning
  popen = subprocess.Popen([self.__growisofs,'-dvd-compat', '-R', '-J', 
   '-Z', self.__device, '-graft-points', burnpath], stderr = subprocess.PIPE)
  popen.wait()
  errs = popen.communicate()[1]
  if type(errs) == types.StringType:
   errs = [errs]
  regMedia = re.compile('media is not recognized as recordable DVD',re.I)
  regSpace = re.compile('(\d+) blocks are free, (\d+) to be written!',re.I)
  regError = re.compile(':-\(')
  for err in errs:
   match = regMedia.search(err)
   if match != None:
    raise self.MediaNotFoundException()
   match = regSpace.search(err)
   if match != None:
    raise self.NotEnoughSpaceException()
   match = regError.search(err)
   if match is not None:
    raise IOError(err)
  return errs

Пользовательский интерфейс

Правило формирования url:


urlpatterns = patterns('',
 (r'^/dvdburn$', 'default.dvdburn.views.index', {'dirname':''}),
 (r'^/dvdburn/(?P[^?]+)/$', 'default.dvdburn.views.index'),
)

все что начинается с /dvdburn попадает в метод index, оставшаяся часть url передается как параметр dirname. Метод view index содержит основную часть логики скрипта. В этом методе к полученному в url пути добавляется путь к корню хранилища фильмов, путь разбивается на составлящие для расставления ссылок на родительские директории, содержимое текущего пути передается в шаблон навигации. Если обнаружен post вызов запускается запись, в текущей версии отображение процесса не реализовано, поэтому пока идет запись страница будет грузиться, по окончании записи отображется шаблон результата.

# -*- coding: utf-8 -*-

from django.http import * 
from django.shortcuts import render_to_response
import os, re, sys, dircache, locale
from libburn import Burner

def index(request, dirname):
 root = u'/storage/video/'
 device = u'/dev/hda'
 
 path = root;
 if dirname != u'':
  path += dirname

 if request.method == 'POST':
  error = None
  try:
   burner = Burner(device)
   burner.burndvd(path)
  except Burner.MediaNotFoundException:
   error = u'вставьте диск с возможностью записи'
  except Burner.NotEnoughSpaceException:
   error = u'недостаточно места для записи'
  except Burner.GrowisofsNotFoundException:
   error = u'Growisofs не найден, попробуйте sudo apt-get dvd+rw-tools'
  except IOError, (errno, strerror):
      print "I/O error(%s): %s" % (errno, strerror)
  return render_to_response('dvdburn/burnresult.html', {'error':error})

 #разобьем путь на составляющие для ссылок назад
 curpath = []
 curpart = None
 parts = os.path.split(dirname)
 while parts[1] != '':
  curpath.append((curpart, parts[1]))
  curpart = parts[0]
  parts = os.path.split(curpart)
 curpath.reverse()

 #формирование списка содержимого директории в формате (путь, название)
 dirlist = None
 if os.path.isdir(path):
  dirlist = map(
   lambda dir: (os.path.join(dirname,dir), dir), dircache.listdir(path)
  )
 
 return render_to_response('dvdburn/dirlist.html', {'curpath': curpath, 'dirlist': dirlist})

Шаблон навигации выводит текущий путь для записи разбитый на части для переходов назад. Затем выводится содержимое текущей директории с ссылками для продвижения вглубь. Внизу страницы — форма с кнопкой "записать".

<p>
{% if curpath %}
<a href='/dvdburn/'>/</a>
{% for part in curpath %}
 {% if part.0 %}
 <a href='/dvdburn/{{part.0|iriencode}}'>{{part.1}}</a> / 
 {% else %}
 {{part.1}}
 {% endif %}
{% endfor %}
{% endif %}
</p>

{% if dirlist %}
Выберите директорию или файл:
<ul>
{% for dir in dirlist %}
 <li><a href='/dvdburn/{{dir.0|iriencode}}'>{{dir.1}}</a></li>
{% endfor %}
</ul>
{% endif %}
<form method='post'>
<input type='submit' value='Нарезать' />
</form>

Шаблон результата выводит ошибку из переменной error или сообщает об успешной записи, если она пуста.

<style>
 .error{background-color: #E0364F; padding: 1em; font-size:150%;}
 .success{background-color: #0CBE3D; padding: 1em;}
</style>

{% if error %}
<div class='error'>
Ошибка: {{error}}
</div>
<p>
Для повторной попытки обновите (F5) страницу.
</p>
{% else %}
<div class='success'>
Запись успешно завершена.
</div>
{% endif %}
<p>
<a href='/dvdburn'>В начало</a>
</p>

Заключение

Что хотелось бы улучшить:

Запись DVD9 на 2 однослойных DVD при необходимости
Отображение процесса записи в процентах, получать информацию можно разбирая вывод growisofs а выводить используя ajax

исходный код скрипта

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

2008-06-10T23:28:00.014+04:00

Немного теории

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

        #сущность пользователь
 class User (models.Model):
  login = models.CharField(max_length=50)
  password = models.CharField(max_length=50)
  email = models.EmailField()
  age = models.DateField()
  
 #сущность запись в блоге
 class Post (models.Model):
  title = models.CharField(max_length=100)
  body = models.TextField()
  poster = models.ForeignKey('User')

Рассмотрим что же мы написали. Запись вида login = CharField(max_length=50) означает, что сущность пользователь обладает свойством логин, которое представлено строкой символов максимальной длиной 50, просто не правда ли? EmailField это поле для хранения адреса электропочты, DateField — для хранения даты, TextField для хранение текста, а ForeignKey определяет ссылку poster на объект класса пользователь. По описанию моделей Django сможет разработает для нас схему базы данных, создаст административный интерфейс и валидаторы. Мы написали всего 10 строчек кода, а получили достаточно много функций, это одна из основных идей рассматриваемого фреймворка — написание приложения с использованием меньшего количества кода. SQL-код сгенерированный Django по описанным моделям:

CREATE TABLE `default_post` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `title` varchar(100) NOT NULL,
    `body` longtext NOT NULL,
    `poster_id` integer NOT NULL
)
;
CREATE TABLE `default_user` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `login` varchar(50) NOT NULL,
    `password` varchar(50) NOT NULL,
    `email` varchar(75) NOT NULL,
    `age` date NOT NULL
)
;
ALTER TABLE `default_post` ADD CONSTRAINT poster_id_refs_id_3b3164d6 
FOREIGN KEY (`poster_id`) REFERENCES `default_user` (`id`);

Приложение

Для завершения настройки нашего проекта создадим приложение — осмысленная часть нашего проекта выполняющая какие-либо действия. В Zend Framework можно найти аналогичный механизм — модуль. Пока не вижу необходимости разбивать наш проект на приложения, поэтому ограничимся одним и назовем его default. Запустите эту команду находясь в директории coblogs python manage.py startapp default Итак, мы получили новую директорию default, в ней вы найдете файл models.py, который содержит описания моделей, весь код описанный далее содержится в этом файле. Так же необходимо отредактировать settings.py, включив default в список установленных приложений

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'coblog.default'
)

Модели

Напомню, что мы создаем сервис коллективных блогов с визуальным/wiki редактором, тегами, кармой и рейтингом постов и комментариев. Попробуем создать костяк моделей проекта, постепенно расширяя его при необходимости. Первая модель — наш дорогой и любимый пользователь, но описывать её не нужно в Django есть встроенный механизм аутентификации включающий модель User. Поля «стандартного пользователя»:

username: имя пользователя (логин), обязательное поле, не более 30 букв, цифр и знаков подчеркивания.
first_name: имя пользователя (по паспорту ;), опционально, не более 30 символов.
last_name: фамилия пользователя, опционально, не более 30 символов.
email: электропочта.
password: хеш пароля, обязательное поле, метод set_password поможет установить хэш по паролю.
is_staff: определяет, может ли пользователь использовать админку.
is_active: определяет, не заблокирован ли пользователь (true — не заблокирован).
is_superuser: если true, то пользователь имеет все возможные права.
last_login: дата и время последнего входа на сайт.
date_joined: дата и время создания аккаунта.

Кроме полей есть полезные стандартные методы, описанные в руководстве. Для пользователя в нашем проекте не хватает одного поля — кармы, добавим его, воспользовавшись механизмом профайлов:

# -*- coding: utf8 -*-  укажем кодировку этого файла

#подлючение механизма моделей
from django.db import models
#подключение стандартной модели пользователя
from django.contrib.auth.models import User
import math

class Profile(models.Model):
        #Порог уровня изменения кармы см. get_karma_delta
        KARMA_DELTA_THRESHOLD = 10

        #ссылка на стандратную модель пользователя
  user = models.ForeignKey(User, unique=True)
        __karma = models.IntegerField(default=0)

        def inc_karma(self, delta):
                """Увеличивает(или уменьшает) карму пользователя на delta"""
                self.__karma += delta

        def get_karma(self):
                """Возвращает карму пользователя"""
                return self.__karma

        def get_karma_delta(self):
                """
                Возвращает на какое значение пользователь может
                изменить карму другого пользователя
                """
                if self.__karma == 0:
                        return 1
                else:
                        return math.ceil(self.__karma/self.KARMA_DELTA_THRESHOLD)

  #Данный класс нужен для появления модели в административном интерфейсе 
                #(об этом в следующий раз)
        class Admin:
                pass

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

AUTH_PROFILE_MODULE = "default.profile"

теперь профиль пользователя доступен при помощи метода get_profile(). Следующие модели — блог (пока содержит только название и описание) и запись в блоге:

class Blog(models.Model):
        caption = models.CharField(max_length=50)
        description = models.TextField()
        created = models.DateTimeField(auto_now_add=True)

        #функция __unicode__ определяет строковое представление объекта
  def __unicode__(self):
                return self.caption

        class Admin:
                pass

class Post(models.Model):
        """ Запись в блоге """
  #ссылка на блог в котором опубликована запись
        blog = models.ForeignKey(Blog)
  #ссылка на пользователя опубликовавшего запись
        poster = models.ForeignKey(User)

        #рейтинг записи
        __rate = models.IntegerField(default=0)

  #заголовок записи
        caption = models.CharField(max_length=50)
  #содержание записи (wiki-размеченный текст)
        content = models.TextField()
  #поле определяет, является ли запись черновиком
        draft = models.BooleanField(default = True)
  #дата создания
        created = models.DateTimeField(auto_now_add=True)
  #дата публикации (устанавливается после снятия опции черновик)
  posted = models.DateTimeField()

        def inc_rate(self, delta):
                self.__rate += delta

        def __unicode__(self):
                str = '';
                if self.draft:
                        str = ' (draft)';
                return self.caption + str

        class Admin:
                pass

И последние две модели — комментарий к записи в блоге и тэг к записи:

class Tag(models.Model):
        """ Тэг (метка) для записи в блоге """
        post = models.ForeignKey(Post)
        tag = models.CharField(max_length=30)

        def __unicode__(self):
                return self.tag

        class Admin:
                pass

class Comment(models.Model):
        post = models.ForeignKey(Post)
        parent = models.ForeignKey('self')
        user = models.ForeignKey(User)

        __rate = models.IntegerField()
        content = models.TextField()
        created = models.DateTimeField(auto_now_add=True)

        def inc_rate(self, delta):
                self.__rate += delta

        def __unicode__(self):
                return self.content

        class Admin:
                pass

Создание структуры базы данных

Пришло время магии :) создадим структуру базы данных из наших моделей. Для этого достаточно ввести команду:

python manage.py syncdb

Сгенерированный SQL-код можно посмотреть при помощи команды:

python manage.py sql default

Манипуляции с моделями

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

#> python manage.py shell
#импортируем стандартную модель пользователя
>>>from django.contrib.auth.models import User
#создадим экземпляр класса User и установим ему пароль '12345'
>>> user = User(username = 'testuser', first_name='Василий', last_name='Пупкин')
>>> user.set_password('12345')
#сохраним пользователя
>>> user.save()
#пользователь был успешно добавлен в БД, посмотрим сгенерированный id
>>> user.id
3L
#импортируем все наши модели
>>> from coblog.default.models import *
#создадим профиль пользователя для testuser и сохраним его в БД
>>> profile = Profile(user=user)
>>> profile.save()
#посмотрим карму
>>> user.get_profile().get_karma()
0L
>>> выведем имена всех пользователей
>>> for usr in User.objects.all() :
...     print usr
root
testuser
#напишем пост
>>> blog = Blog(caption='Блог о Django')
>>> blog.save()
>>> post = Post(poster= User.objects.get(username='testuser'),
caption='Database API', blog=blog)
>>> post.content = 'вот мы вкратце и ознакомились с Django Database API.'
>>> post.save()

Установка и настройка

2008-06-09T22:10:00.025+04:00

Для создания Django приложения понадобятся:

Python
Python-Imaging для работы с изображениями
Subversion (для получения исходного кода Django)
MySQL и MySQLdb для связи БД с Python
Текстовый редактор
Django

Рассказывать буду кратко, применительно к Linux и Windows. Если возникнут какие-либо проблемы или вопросы спрашивайте, отвечу.

Linux

Здесь все просто необходимые программы есть в репозитарии, приведу пример для Ubuntu:

sudo apt-get install python
sudo apt-get install subversion
sudo apt-get install mysql-server
sudo apt-get install python-mysqldb
sudo apt-get install python-imaging

Текстовый редактор подойдет любой: kate — если вы используете KDE, gedit — если Gnome или можете попробовать Komodo Edit.

Windows

Ссылки на дистрибутивы:

Python
python-imaging
Subversion: консольный клиент либо Tortoise — удобная графическая оболочка.
MySQL, MySQLdb
Текстовый редактор подойдет любой, но лучше с подсветкой синтаксиса, например, Komodo Edit, прекрасно справляется как с Python кодом так и с Django шаблонами.

Django

Для получения исходных кодов Django необходимо выполнить команду: svn co http://code.djangoproject.com/svn/django/trunk/ Либо, если вы установили Tortoise, выберите в контекстном меню (правая кнопка в проводнике) «Svn checkout» и введите адрес http://code.djangoproject.com/svn/django/trunk/. Затем запустите консоль и выполните команду: python setup.py install

Создание проекта

Django проект — содержит в себе настройки доступа к бд, настройки Django и исходный код приложений. Перейдите в директорию, где вы собираетесь размещать ваш исходный код и выполните команду: django-admin.py startproject coblogs Эта команда создаст директорию coblogs для нашего приложения и начальные настройки. Необходимо создать базу данных для нашего приложения (убедитесь что MySQL сервер запущен):

$mysql -u root
mysql> CREATE DATABASE coblog CHARACTER SET UTF8;
Query OK, 1 row affected (0.00 sec)

и настроить доступ к ней, откройте файл coblogs/setting.py и измените следующие настройки:

DATABASE_ENGINE = 'mysql'      # 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
DATABASE_NAME = 'coblog'       # Or path to database file if using sqlite3.
DATABASE_USER = 'root'         # Not used with sqlite3.
DATABASE_PASSWORD = ''         # Not used with sqlite3.
DATABASE_HOST = ''             # Set to empty string for localhost. Not used with sqlite3.
DATABASE_PORT = ''             # Set to empty string for default. Not used with sqlite3.

LANGUAGE_CODE = 'ru-ru'

Позволим Django записать свои данные в только что созданную базу:

coblog$ python manage.py syncdb

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

python manage.py syncdb
Creating table auth_message
Creating table auth_group
Creating table auth_user
Creating table auth_permission
Creating table django_content_type
Creating table django_session
Creating table django_site

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (Leave blank to use 'root'): 
E-mail address: a@a.ru
Password: 
Password (again): 
Superuser created successfully.
Installing index for auth.Message model
Installing index for auth.Permission model

Если то что вы увидели сильно отличается от приведенного листинга, скорее всего имеет место ошибка доступа к БД (не запущен сервер, неверные имя пользователя и пароль, ошибка установки драйвера). Проверьте настройки и попробуйте еще раз.

Пара слов о Django

2008-06-04T22:12:00.013+04:00

«The web framework for perfectionists with deadlines»

Django это веб-фреймворк для языка Python, позволяющий быстро разрабатывать динамические веб-приложения. Один из основных принципов звучит как «Don't Repeat Youself» это означает, что единожды написанный код не должен повторяться в другом месте проекта. Что, скажу я вам, значительно отличается от принятой в большинстве проектов тактики Copy & Paste, и это радует. Основные возможности Django:

Object-relation mapper: технология отображения объектов в базу данных. Данная особенность фреймворка позволяет абстрагироваться от SQL запросов при написании проекта и использовать объекты для доступа к БД. Это не избавляет от необходимости писать SQL-запросы, но в большинстве случаев вам не придеться делать этого. Описание объектов доступа к БД в Django, называется моделями. В описании модели указываются тип поля, ограничения накладываемые на содержимое, реляционные связи с другими сущностями. Согласно принципу DRY вы не должны повторять эти данные в другом месте, поэтому по описанию модели генерируется средство управления объектами базы данных (админка) и валидаторы.
Automatic admin interface: автоматическая генерация средства управления объектами бд. Как уже я упоминал ранее по описанию модели автоматически строится админка, которая позволят создавать, удалять объекты и управлять их связями. Хочется отметить, что вы можете влиять через описание модели на интерфейс админки, например, сворачивать по умолчанию не важные поля или встраивать редактор зависимых объектов в редактор родительского объекта.
Elegant URL Design: удобная система построения человеко-понятных урлов используется в Django по умолчанию
Template system: в состав фреймворка входит удобная система шаблонов для разделения логики и представления информации. Django является полноценным MVC фреймворком: ORM предоставляет Модель, шаблонная система — Вид, и то что в Django называется View является контроллером.
Cache system: для высоконагруженных сайтов предоставляется система кеширования, которая позволяет сохранять сгенерированные страницы, или их части в БД или memcached (или еще где-нибудь) и выдавать в следующий раз уже сохраненную копию страницы для уменьшения нагрузки
Internatialization: хотите написать многоязычное веб-приложение? Легко ;) В Django входят средства интернационализации, в коде и шаблонах возможно использование указать что данную строку необходимо перевести на язык пользователя, и если вы предоставили файл перевода для этого языка, система вставит уже переведенную строку (идея gettext).

В общем Django это каркас для веб-приложений, включающий практически все что может вам понадобится, причем все возможности следуют одной общей логике и стилю и легко интегрируются друг с другом. Попробуйте Django, я уверен, вам понравится. Useful links:

Официальный сайт Django
Пишем свое первое приложение на Django — официальный туториал, настоятельно рекомендуется к прочтению
The Django Book
Django users group

Полезные ссылки:

Язык программирования Python — книга Гвидо Ван Россума создателя языка Пайтон.
Русский перевод Django Book
Software Maniacs — проект Ивана Сагалаева, посвященный веб разработке на Django. Здесь вы обнаружите много интересного, особенно рекомендую учебник по блочной верстке и форумы.
Блог Александра Кошелева
Русскоязычное Django сообщество

Введение

2008-06-04T11:46:00.000+04:00

Так получилось, что моя работа связана с web-разработкой, причем на PHP. После участия в паре проектов для меня стали очевидны некоторые минусы PHP в частности и использования компонентных фреймворков (Zend Framework).

Я немного знаю Python и Django, которые, вероятно, не обладают этими недостатками, но возможности применить их в реальном проекте не было. Поэтому я решил параллельно с проектом PHP + Zend Framework на работе, разработать похожий на Python + Django, дабы сравнить эти технологии в "боевых условиях". Весь процесс разработки с комментариями и моими мыслями я буду описывать в этом блоге.

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

Примерный список возможностей:

Коллективные блоги с визуальным/wiki (html на мой взгляд не удобен для этих целей) редактором
Древовидные комментарии к постам
Голование за посты и комментарии
Карма пользователей
Тэги