Разъяснения Рассела

В недавнем посте с интервью с Джанго-разработчиками меня попросили уточнить, что имел в виду Рассел Кит-Маги, говоря про WSGI и валидацию моделей. У меня и у самого эти два пункты вызывали недопонимание, поэтому я попросил его их разъяснить.

Вот перевод его ответа:

Так, первый пункт: WSGI на самом деле хорошо заточен под классическую задачу "показать целиком веб-страницу". Он был спроектирован как самый простой рабочий "наименьший общий делитель" — фактически Питоний вариант CGI. То есть он очень хорошо спроектирован для веба 1995 года, но не настолько хорошо для веба 2011, с его long polling'ом и другими вкусными push-технологиями и серверными плюшками, которые теперь используются повсеместно. Многие уже написали гораздо подробней и об этой проблеме, и о WSGI вообще:

• http://lucumr.pocoo.org/2011/7/27/the-pluggable-pipedream/
• http://www.b-list.org/weblog/2009/aug/10/wsgi/

На самом деле, это не обязательно является проблемой самой Джанго — она использует WSGI всего лишь как API для общения с сервером. Можно использовать любой другой интерфейс, если он кем-то специфицирован. Например, Джанго поддерживает fcgi и mod_python — последний хоть и устарел, но показывает, что метод, который используется для запуска Джанго не зависит от Джанго, как библиотеки по обслуживанию веб-запросов.

Я также должен заметить, что на WSGI тоже возможно реализовать long poll и другие push-технологии, просто это спецификация не обязательно лучше всего подходит для таких нужд.

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

Корень проблемы в том, что Model.full_clean() не вызывается автоматически при вызове save(). Мы не могли так сделать, потому что после апгрейда на Джанго 1.2 (релиз, в котором появилась валидация моделей) код, который до этого работал, стал бы выкидывать всевозможные ошибки валидации.

Это, в свою очередь, привело к проблемам с ModelForm и валидацией уникальности. Документация по ModelForm явно утверждает, что уникальность проверяется в clean() базового класса, и что вы должны вызывать унаследованный clean(), если вам она нужна. Это вместе с тем означает, что пользователь может решить не проверять уникальность, определив метод clean() так, чтобы он не вызывал родительский класс. Включив вызов Model.full_clean() в ModelForm.full_clean(), мы бы изменили это явно задокументированное поведение.

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

Это случай, пожалуй, единственный, который приходит мне в голову, где политика обратной совместимости Джанго стала серьёзным препятствием прогрессу. Во всех остальных случаях, которые я помню, у нас получалось вводить изменения посредством обычного двухшагового цикла релизов, даже когда мы делали значительные изменения, как например синтаксис тега {% url %}.

Russ %-)

От себя добавлю, что если у кого будут ещё вопросы к Расселу, то лучше напишите сразу ему, чтобы я не был испорченным телефоном :-). Я же могу, если что, разъяснить свою позицию.