Oduvan's Web Blog » django

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

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.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 — 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:

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:

А как вы используете джанго на production сервере

Oduvan — Sun, 13 Sep 2009 11:51:06 +0000

Развел небольшой холивар на своем любимом блоге.

Share and Enjoy:

celery – откладываем задачи на потом.

Oduvan — Sat, 01 Aug 2009 09:57:02 +0000

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

Оставил себе таск на выходные порытся и тут. Обо всем напишу тут.

PS: первое, к чему бы я сразу это прикрутил – это отсылка мыла. Ее всегда полезно отложить

Всем удачных выходных.

Share and Enjoy:

django-view-shortcuts

Oduvan — Wed, 29 Jul 2009 18:29:45 +0000

только что наткнулся на этот “АП”, хотя на самом деле – это такой сборничек маленьких полезных функций и пары декораторов. В принфипе ничего сверхестественного. Но смотреть всем обязательно.

Share and Enjoy:

django-csvlog += django-debug-tolbar. Кто кого перехачит?

Oduvan — Tue, 23 Jun 2009 23:40:08 +0000

Пока мой ноут еще жив, а читатели делают ставки, я решил перед сном еще расковырять django-debug-tolbar.

По сути все панели построены на хаках. Т.е. В архитектуре самого движка не закладывалась такая фишка. Т.е. К примеру берут класс BaseCache для из модуля django.core.cache.backends.base делают на его основе наследника, который делает тоже самое, только еще и считает. И заменяют полученный класс в модуле. Т.е. теперь там лежит «тулбарный» класс, и джанго для своей кухни будет брать его, а он уже будет делать свои «темные делишки».

Я для своего csvlog выкавырял оттуда только sql. Теперь я могу еще и вести лог всех запросов, проходящих в вашем апе, и говорить, сколько времени они съели. Сделал сразу компонентную структуру, почти как у этого самого тулбара, так что если что можете отключать.

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

from django.db.backends import util
import time
from csvlog.middleware import glog
class DatabaseStatTracker(util.CursorDebugWrapper):
def execute(self, sql, params=()):
start = time.time()
try:
return self.cursor.execute(sql, params)
finally:
stop = time.time()
glog.dbg(['__SQL__',stop-start,sql,unicode(params)])
util.CursorDebugWrapper = DatabaseStatTracker

Да, и я не тестил, но очень сильно подозреваю, что теперь кто-то из них двоих не сможет считать сюелины, и скорее всего тот, чей ап идет позже в INSTALLED_APPS.

PS: Забыл предварительно проверить свободное место на винте. Бедняга должен умереть свободным.

Share and Enjoy:

Обновления csvlog

Oduvan — Sun, 21 Jun 2009 23:52:40 +0000

Исправил много мелких багов, но надо уже написать нормальную доку. Есть еще идея, взять кусочки из джанго тулбара и к примеру дать возможность выводить все СЮЛ запросы.

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

В папку с аппом добовляем файлик extapp.py

__all__ = ['glog']
from django.conf import settings
if 'csvlog' in settings.INSTALLED_APPS:
from csvlog import glog
else:
class glog():
@staticmethod
def get_log_func(self,*args):
return lambda *args:None
for n in ['err','imp','inf','log','trc','dbg']:
setattr(glog,n,staticmethod(lambda *args:None))

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

from extapp import glog

I love Python!

Share and Enjoy: