N вещей, которые я не люблю в Django

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

Я покопался в Django и нашел N вещей, которые не нравятся в нем лично мне. Не претендую ни на объективную оценку их относительной важности, ни на полноту этого списка. Мне вообще кажется, что это больше всего повеселит поклонников каких-нибудь других фреймворков :-).

ORM не поддерживает агрегацию

Очень часто хочется сделать вещи типа "список всех статей с количеством комментариев к ним", "список юзеров с количеством сообщений от них" — то, что делается через "group by" и "count()". В джанговском языке запросов нет прямого средства для этого, и это очень плохо, потому что очень легко побуждает писать в шаблонах дико неэффективный код:

{% for article in articles %}
{{ article.subject }}, {{ article.comment_set.count }}
{% endfor %}

Он будет делать отдельный запрос с count на каждую строчку.

HTML escape не включен по умолчанию.

Идеология "не додумывать лишнего за пользователя" вышла боком в том, что в шаблонах все переменные по умолчанию выводятся без экранирования HTML. Писать в каждом месте {{ var|escape }} очень легко забывается, и приводит к появлению XSS-уязвимостей. Но самая главная проблема в том, что это сейчас невозможно починить просто, потому что уже написана куча кода, который работает в предположении, что этого нет, а значит будет делать двойное экранирование. Придется чинить сложно.

Авторизация завязана на модель User

Модель User всегда была предназначена для использования в админке. И только потом стало понятно, что сам процесс авторизации — это отдельная удобная штука, которая пригодится и за ее пределами. Авторизацию худо-бедно выдрали, и она даже подходит для общего использования, но она слишком многими вещами завязана на модель User, которую нельзя по-человечески расширить, и приходится пользоваться разными ухищрениями с профилями.

Conditional get бесполезен

Есть такая штука — ConditionalGetMiddleware. Она умеет обрабатывать клиентские запросы с заголовком If-Modified-Since и отдавать короткий ответ "Not Modified", если содержимое не менялось. Это очень эффективная техника кеширования динамических сайтов, которые нельзя кешировать на жесткие промежутки времени. Эффективна она, причем, не столько для клиента, сколько для сервера, который может вообще не генерировать тяжелый динамический контент, если известно, что он не менялся. Но эта middleware как раз этого и не дает сделать: проверка времени последнего изменения делается после безусловной генерации ответа. То есть клиента от перекачивания ненужных данных спасает, а сервер от их генерации — нет.

P.S. Хотя у меня есть идеи для Cicero, как сделать conditional get более интеллектуальным и полезным.

Байтовые строки по умолчанию

Родовая травма софта, написанного в ASCII-мире, не минула и Django. Он изначально был написан с использованием обычных байтовых строк вместо unicode, что означает появление периодических проблем с разными старыми кодировкам, upcase'ами, отсечением символов и подсчетом длины строки.

Однако! Некоторое время назад таки был создан UnicodeBranch, в котором Малколм Трединник переводит Django на внутренне использование юникода. Я там тоже периодически участвую. Бранч очень близок к завершению, поэтому я призываю всех интересующихся скачать его и потестировать на своих проектах.

Context в render_to_response

Render_to_response задумывался как удобный способ сократить пять строк в одну в очень частом случае возврата ответа из view. Случай действительно очень частый, и все им пользуются. И надо ж так было случиться, что эта удобная функция не использует RequestContext, который передает в шаблоны данные по умолчанию, и тоже используется практически всегда. В итоге, практически любой вызов render_to_response сопровождается либо дописыванием одного и того же лишнего параметра, либо порождает разные автоматизирующие решения. А хотелось бы, чтобы это было просто сделано правильно.

Create/Update_object принимают модель

Generic views — замечательная штука, которая позволяет не писать одинаковый код (вывод списка объектов, вывод одного объекта, вывод архива за год и т.п.) Create_object и update_object призваны автоматизировать обработку форм: вывод формы с начальными значениями, прием данных, валидацию, повторный вывод при ошибках, сохранение данных в базу. Все это они делают, достаточно только указать модель данных.

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

А вот если бы вместо модели эти generic view принимали класс формы, все бы было гораздо более шоколадно.

Upload через память

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

Вот. N получилось равным 8.