Oduvan's Web Blog » Django

Django. Быстрый способ сохранить копию объекта

Oduvan — Tue, 12 Jul 2011 00:36:28 +0000

from money.models import Trans
cur_model = Trans.objects.all()[0]
// and make a copy
cur_model.pk = None
cur_model.save() //ha ha

Share and Enjoy:

Методология написания тестов в Django с использованием fixtures

Oduvan — Fri, 10 Jun 2011 19:37:14 +0000

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

Получаем фикстуру

python manage.py dumpdata > all_data.json

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

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

Самое обидное, что Джанго Вам не поможет решить эту проблему. И получите что-то типа
Error: Unable to serialize database:

Нагугил тикет в Django Code:
https://code.djangoproject.com/ticket/6773

К которому прилагается команда, которая показывает Вам «разбитые модели», т. е. модели не полные с неверными данными в ForeignKey .
Я ее немного приукрасил возможностью удалять их автоматом https://gist.github.com/1018947. Для реальных данных удаление автоматом — это не очень обдуманный шаг, но мне сейчас надо получить хоть какую-то фикстуру.

Подержание актуальности фикстуры

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

Сеттингс файл для этого состоит из 3х строчек (settings_lights.py):

from settings import *
DATABASES['default']['ENGINE'] ='django.db.backends.sqlite3'
DATABASES['default']['NAME'] = 'lights.db'

Как известно, в любую команду можно передать не стандартное имя сетингс модуля.

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

python manage.py runserver 0:8001 –settings=settings_lights
python manage.py dumpdata –setting=settings_lights > all_data.json

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

python manage.py migrate –settings=settings_lights
python manage.py dumpdata –setting=settings_lights > all_data.json

Тестирование

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

python manage.py test –settings=settings_lights

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

python manage.py test

А собственно сам текст тестов может выглядить так:

from django.test import TestCase
from django.test.client import Client
from django.contrib.auth.models import User
class SimpleTest(TestCase):
fixtures = ['all_data.json']
def setUp(self):
self.client = Client()
def test_details(self):
print User.objects.all()

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

FIXTURE_DIRS = (
'/path/to/myapp/fixtures/',
)

Проблема с сигналами

Про сигналы в Django вы можете почитать в документции.

Фикстура — это по сути сериализация ОРМ объектов, т. е. объект будет сохранен как json, как просто текст. А значит загрузка из фикстуры — это поочередное добавление всех объектов, а добавление объектов связано с вызовом сигналов, которые в свою очередь могу сами создавать объекты моделей или изменять существующие.

Например. У Вас есть 2 модели счета и транзакции. При добавлении транзакции — дергается сигнал, по которому изменяются балансы счетов участников этой транзакции. При подготовке фикстуры вы создали одну транзакцию между двумя счетами на сумму 100 рублей, т. е. после ее проведения на одном счету прибавится 100 рублей, а на другой вычтится. Вы сохраните полученные данные в файл фикстуры, в которой будут готовые записи со счетами и транзакциями. Во время тестирования этот файл будет загружаться и вначале загрузятся модели счетов – на одном 100, на другом -100. После загрузятся транзакции и дернут сигнал, который еще раз изменит балансы на счетах и мы во время тестирования увидим состояния на счетах 200 и -200.

Решение у джанги есть , но почему-то не документированное, и как по мне — очень не удачное.

В обработчик сигнала передается параметр raw который True во время загрузки фиксутры.

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

def trans_save(sender, instance, raw, **kwargs):
if raw:
return

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

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

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

Спасибо, и удачных Вам выходных.

Share and Enjoy:

Допоплнительные точки расширения Вашего апа

Oduvan — Thu, 01 Jul 2010 16:40:19 +0000

при создании нового джанго проекта я всегда выделяю две папки apps – для моих апов и compat – для сторонних апов, к разработки которых я не имею никакого отношения. Идея в том, что эти апы всегда остаются неприкосновенными для меня, и единственной точкой расширения остаются сеттингсы и возможно доп параметры, при инклюде урлов.

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

catalog

urls.py
views.py
models.py
settings.py
tests.py

для 4 первых файлов можно просто вконце файла добавить строку, которая станет универсальной точкой расширения. Например для views.py

try:
from ex_catalog.views import *
except ImportError:
pass

таким образом, если кто-то будет использовать Вашу апу — точкой расширения будет дополнительная апа ex_catalog, в котором вы можете переопределить некоторый функции из view.py, и при этом ex_catalog не надо добавлять в список апов в настройках.

А теперь главный вопрос этого поста. Почему так не делают?

Share and Enjoy:

Django. URLUp – играться с урлами стало легче

Oduvan — Fri, 04 Jun 2010 11:37:16 +0000

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

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

{% load djoutils_tags_url %}
Ordering:
Name UP
Name Down
Last Name UP
Lase Name Down

Paging:

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

Исходники чуда тега можно увидеть тут.

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

Share and Enjoy:

Django.forms.MultiWidget

Oduvan — Tue, 27 Apr 2010 21:07:56 +0000

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

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

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

Ниже пример поля с датой из 3х выпадающих списков:

from datetime import date
from django import forms
from django.utils.translation import ugettext_lazy as _
class ListMultiWidget(forms.MultiWidget):
def decompress(self,values):
if values:
return values
return [None]*(len(self.widgets))
YEARS_CHOICES = map(lambda a: (a,a), range(1950,2011))
MONTH_CHOICES = map(lambda a: (a,a), range(1,13))
DAY_CHOICES = map(lambda a: (a,a), range(1,32))
SplitDates = ListMultiWidget((forms.Select(choices=YEARS_CHOICES),
forms.Select(choices =MONTH_CHOICES),
forms.Select(choices =DAY_CHOICES )))
class SplitDatesField(forms.Field):
widget = SplitDates
def to_python(self,value):
try:
return date(int(value[0]),int(value[1]),int(value[2]))
except ValueError:
raise forms.ValidationError(_(u'Wrong Date'))

Share and Enjoy:

Конспект с pycamp

Oduvan — Sun, 31 Jan 2010 16:09:24 +0000

Сегодня рано утром вернулся с pycamp, который прошел в Киеве 30ого января в учебном центре i-klass.

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

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

Александр Шигин (гость из солнечного Рамблера) «Почему Python — тормоз и как заставить его меньше тормозить». Были небольшие обзорчики кода, со сравнениями производительности. Сравнение результатов работы алгоритмов, реализованные разными способами — картежи, дикты, классы. Первые быстрее, но мы и так это знали. Хотя местами были довольно интересные результаты. Был упомянут Cython, но только вскользь, хотя мне бы тема была куда интереснее. Так что после в кулуарах мы написали небольшой хелло ворлд на cython, получили сошник и заюзали в самом питоне.

Кратко выглядит примерно так

ваш скрипт

print "Hello World"

скрипт setup.py:

from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
setup(
cmdclass = {'build_ext': build_ext},
ext_modules = [Extension("helloworld", ["helloworld.pyx"])]
)

получаем сошник

$ python setup.py build_ext –inplace

и дальше его используем в ваших скриптах.

>>> import helloworld
Hello World

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

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

Юрий Юревич «Рецепты декораторов». Лично для себя ничего нового не увидел, кроме того, что довольно грамотно все разложено по полочкам и что несомненно помогло упорядочить в голове знания.

Михаил Кашкин (замляк из Днепра) «Работа с хранилищами данных в Google App Engine, отличия от реляционной модели». Я Апсы еще не юзал вообще. Но в скором времени мне таки придется уткнуть свой нос у туда. И пока то, что я узнал — мне не очень понравилось. Реляционных БД там нет вообще. Только их не реляционная БД и мемкеш.

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

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

Александр Соловьев. «Redis: Дикий Запад баз данных». Если коротко — то Redis — этот мемкешед, который сторит данные на винте с промежуточным хранилищем в памяти. С типами данными не только строки но и инты, листы, сеты. И с довольно обширным функционалом для их применения. Мастер-Слейв репликация, кстати только в этом наверно редис проигрывает мемкешу, т.к. мемкеш может использовать несколько серверов и данные между ними отлично распределять ( но редис держит данные на винте а не в памяти ). Ну и конечно же, Александр, как авторитетный велосипедист не мог не написать к редису чего-то своего pyredis ( питонячий клиент для редиса )

Не мог не оценить подачу материала Александром. Очень живо, я даже подумал что презентация получилась в стиле теле-магазина: «Вы хитите это — пожалуйсто — редис отлично с этим справляется, это – и это вы можете сделать как 2 пальца об асфальт и то и то…». Но я бы на его месте такой продукт подавал как Стив Джобс — Макбук Аир. «Представте систему, которая быстрее мемкеша но данные сторит на винте, с типизацией ячеек и т.д. и т.п. И в конце Редис» Ну что-то в этом стиле.

В любом случае, Александру спасибо. Будем смотреть, будем пробовать. Интересно, он кешовый бекенд для редиса на джанге уже написал?

Владимир Пузанов и Владимир Кирилов «Расширения и встраивание Python». Эти два молодых хакера рассказали о том где можно применять питон, с чем и как его можно связывать. Jython, IronPython и многое другое, что я еще не запомнил. Надеюсь где нить раздобыть их презентацию. Но для себя отложил Stackless Python — у него очень «крутые» треды, на сколько крутые — я уже буду пробовать ручками сам. И когда я говорю о Stackless мне уже какой раз предлогают глянуть на greenlet. Общее впечатление о докладе осталось очень хорошее – хороший обзор, живая подача материал и оставило много вопросов (как и должно быть в подобных докладах). В конце парни показали прикольный примерчик как они питоном хачат сафари и меняют в нем титл через его жсный движок. Хотелось бы ответить всем бегающим по залу участникам с вопросам «Нафига надо было хачить софари». Объясняю — просто так!!! Просто точка ( довольно прикольная ) в докладе о расширениях и встраиваниях питона, обидно, что многие из всего доклада запомнили только эту точку.

Андрей Мишковски «Использование Python в ГИС» . Проблематика Гиографические Информационные Системы для меня была нова, но подача информации была доступна и понятна даже слушателю не знакомым с темой. Так что если кто хочет может просмотреть презентацию, и дождаться выхода видео.

Сергей Кирилов. «WebSockets в twisted». WebSockets — это новое расширение протокола HTTP в сторону двухстороннего взаимодействия клиент-сервер с одним коннектом, которая описана в стандарте HTML5. Поддерживается пока не всеми ( поэтому пользуемся библиотечкой, которая подменяет стандарт для тех, кто его еще не поддерживает ). Я мог пропустить, но по моему twisted-у был отведен один слайд, на котором выведено 42 строчки кода и сказано, что их 42 Кстати нагугли и хабровскую статью на эту тему.

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

Сергей, если у вас сохранилась копия этой болтавни в чате — выложите куда-то, было прикольно

И последний из понравившихся мне докладов был у Ивана Моргуна, сразу после нее я и убежал, т.к. надо было успеть на поезд обратно. Доклад был о «Работа с платежными системами в Django (PayPal, WebMoney)». Из джанго я ничего интересно для себя не вынес, но некоторые интересные моменты для PayPal подчеркнул.

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

Еще о pycamp:
curvedbrain.org “Мысли по мотивам PyCamp Kyiv”
Макс Ищенко “мысли к вчерашнему pycamp”
Vladimir PyCamp впечатления
Дмитрий Гайворонский “PyCamp @ Kiev, 30 Jan 2010″
… пишите в комментах ссылки на свои посты о кемпе …

Share and Enjoy:

Нашел чо посмотреть.

Oduvan — Thu, 14 Jan 2010 22:38:32 +0000

Видео с DjangoCon 2009.

http://djangocon.blip.tv/

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

Share and Enjoy:

Кешируйте с умом.

Oduvan — Fri, 11 Dec 2009 21:54:40 +0000

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

Кеш. Я им пользуюсь для того, чтобы данные, которые я долго вычисляю — положить в память куда нить, чтоб если они понадобились — быстро их оттуда взять. Ну а если их там нет, то просто пересчитать и положить. Если вы им пользуетесь также, то читайте дальше иначе напишите комментарий, который начнется со слов: «Тю, блин, а я его совершенно по другому юзаю, глянь…»

Т.е. на сетах и гетах все сводится к примерно следующему алгоритму.

from django.core.cache import cache
def setter(key,l_value,timeout=0):
val = cache.get(key)
if val is None:
val = l_value()
cache.set(key,val,timeout)
return val

где l_value — это ссылка на функцию, значение которой будет получено, в случае если его нет в кеше.

Вот этот умопомрачительный алгоритм у меня лежит в основе кеширования.

Хух… если у вас также, то идете дальше. Надеюсь сейчас осталось достаточно народу.

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

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

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

Тут просто тьма тьмущая узких мест

1.Старт у системы должен быть особый. Т.е. в нулевой точке в кеше уже должны быть часто доступные данные.
2.У вас двойные данные в кеше, т.е. две копии, а ведь часто бывает и такое, что трудновычисляемые данные — это и большие данные.
3.И последнее — если процесс, который вычисляет заекспаревшиеся данные — умирает. То умирают все. Явно теряем в отказоустойчивости.

Кратко опишу свой алгоритм решения, и построенный на нем джанговый кешовый бекенд (за базовый взят мемкешовый).

Если в ячейку с ключем класть не данные, а хеш из двух значений — данные, и время, когда их надо обновить. (ТАДАМ избавились от второго пункта)

А что если ты перед началом вычислений будеш класть в другой системый и уникальный ключ в кеше время, когда первый, начавший вычисления – планирует их закончить. А остольные процессы, которые захотят получить данные и не увидят их — смогут орентироваться на системный ключь, чтоб понимать, что данные скоро будут и их необходимо подождать или мы не дождались и попробуем еще раз. (ТАДАМ избавились от первого и третьего)

А теперь скучный код. Чтоб легче было читать — его необходимо скрестить с алгоритмом, который я описывал выше. И если функция гет — вернет None то эти данные сразу начнут вычисляться.

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

from django.core.cache.backends.memcached import CacheClass as BaseCacheClass
from datetime import datetime,timedelta
from time import sleep
from random import random
ADDITION_EXP_TIME = 20
TIME_FOR_CREATE = 5
class CacheClass(BaseCacheClass):
def add(self, key, value, timeout=0):
timeout = timeout or self.default_timeout
value = {'v':value,'e':datetime.now()+timedelta(seconds=timeout)}
super(CacheClass,self).add(key,value,timeout+ADDITION_EXP_TIME)
def set(self, key, value, timeout=0):
timeout = timeout or self.default_timeout
value = {'v':value,'e':datetime.now()+timedelta(seconds=timeout)}
super(CacheClass,self).set(key,value,timeout+ADDITION_EXP_TIME)
def get(self,key, default=None):
wait_next_val = 0
while True:
wait_next_val += 0.1
value = super(CacheClass,self).get(key,default)
now = datetime.now()
if value is not None and now<value['e']:
return value['v']
wait_system_key = 'wait_system__%s__wait_system'%key
wait_system = super(CacheClass,self).get(wait_system_key)
# if you find expired key first or you don't wait the next person
if wait_system is None or wait_system<now:
super(CacheClass,self).set(wait_system_key,datetime.now()+timedelta(seconds=TIME_FOR_CREATE),TIME_FOR_CREATE + 5)
return None
#if somebody already getting a new value
if value is not None:
return value['v']
sleep(random()*wait_next_val)

И на всякий случай. Если вы все таки считаете это отличной идее. Кладем это в файлик с незамысловатым названием smart_cache.py рядом с settings.py, а в settings.py записываем

CACHE_BACKEND = "smart_cache://127.0.0.1:11211"

Share and Enjoy:

WinPdb дебажить джангу стало еще легче

Oduvan — Mon, 09 Nov 2009 20:59:10 +0000

Хоть простой и нативный pdb и так нам давал все что надо, все же приятно понимать, что есть еще чтото, что может сделать наш девелов приятней. WinPDB – одна из этих приятностей (наткнулся на нее вДжанговкой Вики) . Если коротко – это дебагер с приятным пользовательским интерфейсом, которой кросc-платформенный к слову говоря.

Пользовать легко.
Раньше вы коде оставляли:

import pdb; pdb.set_trace()

А теперь получается чуть длиннее:

import rpdb2; rpdb2.start_embedded_debugger('mysuperpassword')

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

Запускаем winpdb. File => Attach. В появившемся окне вводим наш пароль mysuperpassword. В полученном списке выбираем наш.

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

P.S. …

И Django Cheet Sheet, кто еще не знает…
И надо будет испытать django-tinymce

Share and Enjoy:

Urls и views в одном файле.

Oduvan — Thu, 01 Oct 2009 15:55:38 +0000

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

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

Итак главный urls.py имеет обычный вид

from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^someurl/',include('someapp.url_view')),
)

/someapp/url_view.py – тут у нас сбстно и хранятся вьюхи с урлами. Как видите, декоратор tourl нам земенил запись в urls.py

from django.http import HttpResponse
from tourl import tourl
@tourl(r'^and/$')
def and_(request):
return HttpResponse('and')
@tourl(r'^gg/$')
def index(request):
return HttpResponse('OK')

/someapp/tourl.py – ну и код самого декоратора

from django.conf.urls.defaults import *
import sys
import functools
def tourl(url_patern,*args,**kwargs):
def paramed_decorator(func):
@functools.wraps(func)
def decorated(self):
return func(self)
module =sys.modules[func.__module__]
if not hasattr(module, 'urlpatterns'):
module.urlpatterns = patterns('',)
module.urlpatterns += patterns('',
url(url_patern,decorated,*args,**kwargs),
)
return decorated
return paramed_decorator

Помоему и симпотично и по производительности не бьет. Вобщем конфетка! Что скажите?

PS: Добавил снипет.

PSS: В снипетсах посоветовали добавить functools.wraps

PSS: А еще можно использовать и так

from django.http import HttpResponse
from tourl import tourl, patterns,url
@tourl(r'^and/$')
def and_(request):
return HttpResponse('and')
def index(request):
return HttpResponse('OK')
tourl(r'^gg/$')(index)
def ordinary(request):
return HttpResponse('Ordinary')
urlpatterns += patterns('',
url(r'^ord/$',ordinary)
)

Share and Enjoy: