Последнее время мне всё более и более странным (я бы даже сказал “недальновидным”) кажется решение авторов оригинального туториала по Джанге показывать именно такой формат расположения файлов в джанге (и уж тем более то, какой sys.path они там используют): в туториале все файлики, созданные с помощью startproject, лежат в одной директории вместе с приложениями. Соответственно, все импорты выглядят как from someproject.someapp import views.

Мне понятно, откуда ноги растут — на деле у них все приложения лежат в sys.path, и потому импортируют они оттуда как from someapp import views, а проект — это лишь настройки да корневой конфиг урлов. Тогда можно родительскую для всех проектов директорию положить в sys.path, и менять только DJANGO_SETTINGS_MODULE. Но в любом случае одним интерпретатором питона для двух джанговских проектов не обойдёшься (спасибо этому самому DJANGO_SETTINGS_MODULE), а способность к лёгкому созданию дистрибутива и его распространению страдает порядочно (что особенно важно для опенсорсовых проектов).

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

project/
  apps/        # собственно приложения
  template/    # шаблоны
  static/      # статические файлы — картинки оформления, стили, JS
  media/       # файлики, загруженные пользователями, не версионируется
  locale/      # переводы
  compat/      # тут библиотеки типа django-atom
  manage.py    # файлы, относящиеся к описанию проекта
  settings.py
  urls.py
  ...

При этом в sys.path добавляется сама директория проекта, DJANGO_SETTINGS_MODULE становится равен settings, а в settings.py двумя строками кода в sys.path добавляется и apps/ с compat/¹. В результате все импорты простые и не содержат имени проекта (что тупо хотя бы потому, что я не могу склонировать проект рядом и поэкспериментировать в нём из-за того, что будут проблемы с импортами), а проект становится достаточно независимой вещью, которая для разворачивания на каком-то сервере требует только Джангу и библиотеки, которые достаточно распространённые и/или большие для того, чтобы не включать их в проект.

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

Few days ago there was a lot links on the Internet to gitshelve, which implements persistent versioned storage of objects in the git. I’ve read it description and realized that there are few serious design flaws:

• Can store only strings
• Uses subprocess.PIPE for interconnection with git
• Uses bunch of C+Perl+Shell code in Python library instead of using another Python library ;-)

Из исходника и обсуждения в jabber-конференции pythonua@cjr родился прикольный список соответствия языков программирования стилям музыки.

[UPD от 12 ночи]

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

Но вот не так давно обсуждали его в джаббер-конференции pythonua@c.j.r (кстати, официальная конференция python.com.ua), где появилась идея слегка его проапгрейдить до возможности задавать темплейт из view (когда одна вью может выдавать различные странички). В принципе, идея усложнения декоратора мне не особенно нравится (да и потом, кому надо — может переделать себе, благо несложно), но по размышлении я увидел, что особенного усложнения нету, плюс сохраняется обратная совместимость полностью (что важно, потому как мне есть и где использовать новую фичу, но не очень хочется ломать все вьюхи, использующие старую версию ;).

В процессе работы над одним проектом я в очередной раз столкнулся с тем, что джанговский ImageField меня ну никак не устраивает — в нём отсутствует возможность ресайза при аплоаде, некак загружать картинки в разные директории¹, кроме как по дате, ну и динамически назвать файлик² тоже нельзя.

Только что зашёл ради интереса на проверялку скорости от MooTools, проверился в двух браузерах - в Firefox 2 и в Conkeror’е (который суть XULRunner - тот же движок, что и Firefox 3).

И вот что интересно: несмотря на относительно немалое отставание jQuery в обоих браузерах (ну, ценим мы его не за это :D - плюс там старый 1.2.1 тестируется ещё), наблюдаются интересные результаты: в Conkeror’е отставание меньше, чем в FF2!

Сами результаты:

           FF2  Conkeror
Prototype  307   240
MooTools   295   220
jQuery     808   591

Хотя только что взял и посчитал соотношение - jQuery против MooTools выходит 2,74 против 2,67. Лучше считать абсолютную разницу, куда интереснее. ;-)

Как проходит дебаг джанги обычно? В 90% случаев хватает внимательно изучить желтенький джанговский трейсбек ошибки, со всеми переменными и кодом, ещё в 9% хватает расставить print‘ы, а в совсем запущенных случаях приходит на помощь winpdb.

Но после одной отличной новости можно значительно облегчить себе жизнь - перестать расставлять print’ы, перестать изучать трейсбеки досконально и отказаться от удалённого дебаггера, заодно показав язык Pylons’ам, в которых такая штука есть давно. :-)

Вообще я этот пост прочёл и пролистал, когда он появился неделю назад. А тут случайно наткнулся на него ещё раз и решил попробовать. Фантастика! :-) Встречайте - консоль прямо в трейсбеке. :) Я сделал скрин (250 кб) моих первых шагов в неизведанное. ;-)

Рекомендую. Офигенская штука. Сам по себе werkzeug небольшой, стартует быстро (быстрее джанги), проблем не вызывает и вообще… просто красота теперь. :)

Известная штука, что у Django есть статическая (неизменяемая официально поощряемыми путями) модель User и костыль для дополнительных полей (которые может каким-либо образом использовать приложение) в виде настройки USER_PROFILE, указывающей на модельку-профиль. В результате использования такого костыля, если не делать дополнительных телодвижений, количество запросов возрастает (пример для данного блога, где каждому комментирующему ставится ссылка на его сайт) на число комментариев (даже не комментировавших, а комментариев!).

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

Потому, после продолжительных колебаний и сомнений, я решил сделать всё радикальнее - удалить всю модель UserProfile, применив вместо неё monkey patching к стандартной модели:

User.add_to_class('site', models.URLField(verify_exists=False, blank=True))
User.add_to_class('email_new', models.EmailField(blank=True))

User._meta.admin.fields += (
    ('Byteflow Extensions', {'fields': ('site', 'email_new')}),
    )

Конечно, главная проблема здесь - это то, что способ совершенно не стандартный и вряд ли кто-то будет ожидать, что табличка auth_user будет меняться. Но такой способ настолько выгоднее и удобнее, что я решил наплевать на эти трудности. :-)

И ещё одно - спасибо Амиту, который и показал конкретно, как это сделать. ;-)

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

def render_to(tmpl):
    def renderer(func):
        def wrapper(request, *args, **kw):
            output = func(request, *args, **kw)
            if not isinstance(output, dict):
                return output
            return render_to_response(tmpl, output, 
                   context_instance=RequestContext(request))
        return wrapper
    return renderer

Конечно, можно дописать пару строк к возврату враппера и получить в принципе работающий механизм:

        wrapper.__name__ = func.__name__
        wrapper.__doc__ = func.__doc__
        return wrapper

Но на самом деле это не самый красивый метод. Куча всяких руководств для начинающих по написанию декораторов всегда рекомендует юзать модуль Мишеля Симионато - decorator. В принципе, всё конечно просто отлично, но есть у него огромный недостаток - это дополнительная библиотека, в то время как есть отличное решение из стандартной библиотеки - functools.wraps. Его использование ничем не отличается от использования decorator‘а:

from functools import wraps

def render_to(tmpl):
    def renderer(func):
        @wraps(func)
        def wrapper(request, *args, **kw):
            output = func(request, *args, **kw)
            if not isinstance(output, dict):
                return output
            return render_to_response(tmpl, output, 
                   context_instance=RequestContext(request))
        return wrapper
    return renderer

И всё становится белым и пушистым. :-) Один момент непонятен - почему его не пишут во всех этих руководствах для начинающих? Ведь эти начинающие с течением времени становятся продолжающими и точно так же не знают о простой и приятной штуке прямо в stdlib‘е.