Ведущие разработчики о будущем Джанго

Во время последнего DjangoCon я пересёкся с несколькими из ведущих разработчиков и попросил их поделиться своими взглядами на будущее Джанго. Идея едва ли свежая — любого лидера чего бы то ни было постоянно достают вопросами о БУДУЩЕМ. Но у меня был и свой резон. По прошествии некоторого времени вдали от Джанго-разработки, мне было интересно, куда она движется, а также хотелось найти в себе мотивацию снова включиться в процесс.

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

Джейкоб Каплан-Мосс

Джейкоб — один из первоначальных разработчиков Джанго. Его диктаторская воля часто является последней в разрешении споров раз и навсегда.

Что ждёт Джанго дальше?

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

Что бы лично вам хотелось видеть в Джанго?

Это ни в коем случае не "официальная" позиция, но вот несколько вещей:

замена auth на что-нибудь получше, более гибкое
Джанго не очень хорошо подходит для real-time веб-сервисов, было бы хорошо иметь такую поддержку
… и хотя это не личная хотелка, поддержка NoSQL — это то, чего, кажется, хочется очень многим

Ждёт ли нас обратно несовместимая "Джанго 2.0"?

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

Однако у нас в Яндексе ни разу не было по-настоящему обратно совместимого обновления…

Не страшно поломать что-нибудь местами, главное — не всё сразу. У нас для этого есть deprecation warnings, чтобы дать людям время поменять код.

Политика "не ломания" — то, почему у нас есть такое хорошее сообщество.

Рассел Кит-Маги

Рассел — Джанго-хакер со стажем, компетентный во всех областях фреймворка. Он также является президентом Django Software Foundation.

Что ждёт Джанго дальше?

По большому счёту, нам нужно расширять сообщество. Мы должны предлагать наш продукт для правительственных и корпоративных клиентов. Это как раз работа для DSF, он не должен заниматься только Джанго непосредственно.

Технически же нам нужно сделать много вещей, например:

полнее использовать новую питонью систему пакетов
выбрать один Javascript-фреймворк, с которым работать
сейчас Джанго не умеет real-time веб правильно, но тут WSGI не даст нам переделать архитектуру

Не стоит ли начать делать с нуля обратно несовместимую Джанго 2.0?

Нет. Большая часть ядра Джанго, вообще-то, довольно неплоха. Да, у нас были определённые ошибки — например, валидация в моделях — но в целом всё хорошо.

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

Алекс Гейнор

Алекс — очень (самый?) плодовитый из ведущих разработчиков, берущийся за пугающие рефакторинги больших подсистем. В последнее время также известен работой над PyPy.

Что ждёт Джанго дальше?

Починка настроек!

Мы разговаривали сразу после выступления Глифа Лефковица, в котором он заклеймил джанговские настройки, как "гигантскую глобальную переменную, в которой всё как-то случается", и вдруг стало понятно, что это не нравится и всем остальным тоже.

Также на очереди рефакторинг приложений. Возможно, нам надо посмотреть на объекты приложений из Flask, хотя бы для вдохновения.

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

Надо ли делать обратно несовместимую Джанго 2.0?

Нет, Джанго 2.0 быть не должно. Переписывание — это забывание полученных уроков.

Эндрю Годвин

Эндрю — первоначальный автор известной миграционной утилиты South. Работает в ep.io и является гуру массового автоматизированного деплоймента Джанго-сайтов.

Что ждёт Джанго дальше?

Ядро, на самом деле, в порядке, поэтому наша главная задача — приведение различных компонент Джанго в более пригодное состояние. "Аджаксовые" штуки не особенно важны.

А какая часть ядра, по вашему мнению, хуже всего?

Наиболее проблемная область — это шаблонная система. Она, по сути, такая же, как была в 2006 году, и нуждается в улучшении.

Нужна ли нам обратно несовместимая Джанго 2.0?

Нет, мне кажется, что нам удаётся меняться пошагово, как это было с "newforms", которые появились под новым именем, а потом были переименованы в "forms" через какое-то время. Джанго 2.0 сама случится естественным образом.

Заключительные мысли

Викторина: кого из них вы знаете? :-) — Круглый стол ведущих разработчиков на DjangoCon 2011

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

Ещё одна вещь, которую стоит отметить, это стабильность Джанго во многих смыслах. В смысле устойчивости вашего продакшн-сайта она была стабильна уже очень давно. Потом, с выходом 1.0, она стала формально стабильной в отношении опубликованных API. А теперь ясно, что и в ближайшее время её не ждут никакие архитектурные потрясения.

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

Ну и напоследок хочу сказать, что с этими ребятами было очень приятно поговорить :-). Спасибо вам!

Комментарии: 22

oeuoeu

Спасибо за эти интервью. Очень хорошо, что они не идут дорогой Гнома 3.0 или четвёртых кед. :)

За себя скажу, что после года интенсивной разработки хочется вот чего:

NoSQL из коробки очень нужен
Аякс и риалтайм тоже, потому что сейчас очень трудно всё это делать. Например, чтобы обновлять страницы частями, мне пришлось сделать django-partial-page, который патчит Блок и перехватывает содержимое.
У тебя глючный JS в комментах, жму enter, перенос вставляется, но курсор не переходит на новую строку.
Права доступа - огромный головняк, и в 1.3 они сильно лучше не стали, потому что вызывать has_perm очень неудобно. Вот, к примеру, что сейчас мы делаем на своём проекте - это фреймворк, чтобы в объектах были права доступа, и во в вьюшках тоже, и специальный тег, чтобы на странице не писать кучу if-ов, а вставить {% check_perm app_name.view_name %}, и права проверялись именно те, что во вьюшке. (Пока что код просто дублируется.)
Возможно это проще решить с NoSQL, но ОРМ должен быть поставлен под контроль, а именно под version control.

Владимир Епифанов

Что такое «NoSQL из коробки»?

aoeuaoeu

Чтобы ОРМ на нём работал. Мне, когда я начинаю новый проект или делаю маленькую страничку, ПГ не нужен. Да и в Монге сейчас индексация очень хорошо работает.

http://vapask.yandex.ru

Возможно это проще решить с NoSQL, но ОРМ должен быть поставлен под контроль, а именно под version control.

South разве не решает поставленную задачу?

Вап

Есть некоторые моменты, которые мне в Django непонятны. Например, почему в PositiveIntegerField можно записать отрицательное значение. Или почему иногда генерируется невалидный для некоторых баз запрос(например, подзапрос с LIMIT и OFFSET для MySQL будет неправильным). Поэтому в будущих релизах хотелось бы увидеть более полную и подробную документацию и уменьшение количества неочевидных вещей.

profiles.google.com/vlad.sirenko

Из коробки:

# aptitude install python-django

A не из коробки, те как сейчас:

$ hg clone https://bitbucket.org/wkornewald/django-nonrel

Ivan Sagalaev

Вряд ли Володя спрашивал про термин "из коробки". Рискну предположить, что речь о том, что поскольку термин "NoSQL" означает очень разные решения, что его невозможно "поддержать из коробки". Обычно люди под "NoSQL" подразумевают одну только MongoDB.

pySilver

Иван, поясните пжлста 2 момента:

сейчас Джанго не умеет real-time веб правильно, но тут WSGI не даст нам переделать архитектуру

Что подразумевается под real-time web? Чего не хватает в джанге?

Большая часть ядра Джанго, вообще-то, довольно неплоха. Да, у нас были определённые ошибки — например, валидация в моделях — но в целом всё хорошо.

Почему валидация в модели дурной тон?

Я всего пару месяцев работаю плотно с django, пришел из мира PHP (Zend Framework), неудобством для меня является некоторое упрощение абстракции в django т.е. view напрямую общается с моделями и менеджерами. Это упрощает разработку согласен, но для большого проекта лично мне непривычно общатся напрямую с ORM, при изменениях приходится менять 10 мест, вместо одного.

В Zend Framework я обычно строил Service Layer находящийся над Data Layer - валидация происходила именно в сервисном слое, вьюшки общались только с сервисным кодом. Грубо говоря Service Layer это бизнес логика, ему не интересно откуда пришел запрос и как хранятся данные, но он знает как их валидировать и интерпретировать.

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

Но пока что ни одного django проекта с Service Layer я не видел, и кажется мне это не спроста. Почему так не делают?

demiazz

Иван, так уж получилось, что не смотря на то, что работаю Django-разработчиком, но было время на близкое знакомство с Rails 3.

Очень интересно было бы узнать ваше мнение, как специалиста, довольно долго разрабатывавшего под Django, по поводу того, не стоит ли чего-нибудь заимствовать у столь быстро и резко развивающихся Rails 3? Я говорю не про прямое копирование функционала "в лоб", но вообще про взятие идей, и адаптации к Django.

P.S. Вопрос не холивара ради, как бы холиварно он не звучал.

Ivan Sagalaev

Этот вопрос тогда к вам, а не ко мне: я в Rails не смотрел :-).

Ivan Sagalaev

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

А про валидацию коротко не отвечу, потому что не знаю, что конкретно Рассел имел в виду. У меня к ней есть свои невнятные претензии, но речь не про меня… Постараюсь его порасспросить ещё :-).

oleg

Иван, а про переход Django на Python3, на DjangoCon, речь не заходила? Или про возможные планы?

Ivan Sagalaev

Заходила! Джейкоб выразился примерно так: "Когда речь заходит про Питон 3, люди обычно указывают на кого-то и говорят, что те их держат. Сначала это были драйверы БД, потом WSGI. Так вот теперь, если вы не заметили, все показывают на нас! Так что настало время наконец сделать это."

Ну и собственно: https://code.djangoproject.com/changeset/16742

Андрей Богомолов

Иван, по поводу ваших слов:

В теории должно мешать то, что Джанга рассчитана на работу в синхронной модели, а real-time серверы делают асинхронно обычно.

меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и сделать джангу асинхронной (правда с учетом всех багов гринлетов и того, что неблокирующими будут лишь операции с бд)

тот же вопрос иногда встает при сравнении twisted/tornado c stackless (почему все так тащаться от первых, когда второй выглядит намного удобнее для написания таких приложений), но это уже совсем другая тема...

Google user

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

Нормальная интеграция модели с системой миграций, например South, лучше вообще включить его в Джангу. Гадать где там возникнет очередная проблема с наследованными классами моделей и т.д. несколько утомительно. Между разработчиками South и Django не хватает взаимодействия.
Нормальный механизм дампа и рекавера. Существующий написан левой пяткой никуда не годится. Дамп таблицы с 10.000 записей требует 8гб озу на борту, понятно почему, но непонятно почему это так. Зачем перегонят весь пирог через память? Без этого оснастки и весь связанный с ними механизм крайне ограничен.
Шаблонизатор бесшовно работающий как с локальными файлами, так и с шаблонами в базе.
Внятный менеджер конфигураций, ну хотя бы как в Tornado, только с возможность разделения конфига для разных приложений и сценариев. Все существующие решения слишком разношерстны и имеют свои проблемы.

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

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

Google user

меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и сделать джангу асинхронной (правда с учетом всех багов гринлетов и того, что неблокирующими будут лишь операции с бд)

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

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

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

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

Что будет при этом с 3-rd party страшно даже подумать. Даже в идеальном случае скорее всего получится маловразумительный клон джанги с крайне ограниченной функциональностью и сильно проигрывающий изначально асинхронным решениям. При этом очень непопулярный и редко используемый клон.

Если нужна асинхронка и неизбежно использование django, то лучше вывести колбеки на уровень непосредственно обработки, привязав их к какому ни будь асинхронному воркеру на twisted или tornado, который принимают, например, строку запроса к стороннему API и по завершению обращения дергают backurl с передачей ответа обратно в джангу. Если нужен, например, генератор тяжелых отчетов, то таким образом можно дернуть сторонний скрипт, подключенный к модели приложения.

Предок

чтобы на странице не писать кучу if-ов, а вставить {% check_perm app_name.view_name %}, и права проверялись именно те, что во вьюшке. (Пока что код просто дублируется.)

— oeuoeu, Иногда лучше почитать доку https://docs.djangoproject.com/en/dev/topics/auth/#id9

В Джанге, как раз, наоборот, вопрос распределения прав решен очень гибко и правильно, особенно пообъектное распределение прав. Не нравится писать бэкенды - подключи django-rules.

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

pySilver, - ответ на Ваш вопрос. Потому что Zend_Db_Table и близко не валялся с Джанго-ОРМ, потому его костылями и обвешивают. Более мудрые его вообще не используют, а интегрируют Доктрину.

Предок

Почему-то вспомнил http://lurkmore.ru/%D0%93%D0%BE%D0%B2%D0%BD%D0%BE%D0%BA%D0%BE%D0%B4

В Индии с некоторых времен существует практика оценки производительности труда программиста на основе количества написанного кода. Чем больше кода, тем больше программист работает, и, следовательно, выше его оклад. Шустрые индусы быстро сообразили, как обманывать неквалифицированных заказчиков. В результате чего можно встретить подобные шедевры (и это только цветочки!): [скрыть]

if (true) {
    // какой-то код
} else {
    // a вот тут чистый profit
}

Менее очевидный вариант:

if(var)
{
...
}
else if(!var)
{
...
}
else
{
// чистые деньги
}

Писать много кода - не проблема. Проблема писать мало кода. Очень распространенная проблема. написать лаконичную программу сложнее чем написать большую проблему. Идеал - это года нечего добавить, и нечего отнять.

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

Предок

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

— То же самое. Это поведение задокументировано (уж не буду тыкать ссылкой). Нужно внимательно читать доку. И для такого поведения есть обоснования.

Андрей Богомолов

Можно ли запустить джанго на торнаде или на стеклессе?

как можно ставить эти два решения в один ряд? торнадо - это как раз ближе к twsited.

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

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

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

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

Малореально полностью обернуть ОРМ в асинхронку

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

protractileaigu

Nice write up, thanks for sharing.

Провёл анализ Django с версии 1.3 до версии 1.8

Провёл анализ рассылки Python Weekly? там часто можно встретить приложения.

Охват получился:

Django с версии 1.3 до версии 1.8

Что меня расстроило в 2011 году?

Тогда весь запад старался в Django использовать всё, что угодно кроме кода Django. Мне это очень не нравилось и я всё такие решил, что это не верный подход и решил для себя, что буду стараться решить всё при помощи чистого Django или Python.

Сейчас же в 2015 году (апрель), когда провёл анализ, запад отказался от идеи применения в Джанго принципа (использовать всё, кроме Джанго).

Все поняли, что сложности ни к чему и чистота кода, читаемось, лёгкость обновления превыше всего.

Это сильно порадовало.

Слова ДЖЕЙКОБА КАПЛАН-МОССА работают на практике, действительно в Джанго включается то, что хотят видеть пользователи. Это включение в 1,7 South, в 1,8 Джинжу.

Кстати, если посмотреть например вопросы и ответы Хабра, то явно видно, что рунет отстаёт в этом вопросе на те же 4 года.

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

Читать статью полностью здесь:

http://spb-tut.ru/guest/pages/47/

Добавить комментарий

oeuoeu
Спасибо за эти интервью. Очень хорошо, что они не идут дорогой Гнома 3.0 или четвёртых кед. :)

За себя скажу, что после года интенсивной разработки хочется вот чего:
1. NoSQL из коробки очень нужен
2. Аякс и риалтайм тоже, потому что сейчас очень трудно всё это делать. Например, чтобы обновлять страницы частями, мне пришлось сделать django-partial-page, который патчит Блок и перехватывает содержимое.
3. У тебя глючный JS в комментах, жму enter, перенос вставляется, но курсор не переходит на новую строку.
4. Права доступа - огромный головняк, и в 1.3 они сильно лучше не стали, потому что вызывать has_perm очень неудобно. Вот, к примеру, что сейчас мы делаем на своём проекте - это фреймворк, чтобы в объектах были права доступа, и во в вьюшках тоже, и специальный тег, чтобы на странице не писать кучу if-ов, а вставить {% check_perm app_name.view_name %}, и права проверялись именно те, что во вьюшке. (Пока что код просто дублируется.)
5. Возможно это проще решить с NoSQL, но ОРМ должен быть поставлен под контроль, а именно под version control.
Владимир Епифанов

Что такое «NoSQL из коробки»?
aoeuaoeu

Чтобы ОРМ на нём работал. Мне, когда я начинаю новый проект или делаю маленькую страничку, ПГ не нужен. Да и в Монге сейчас индексация очень хорошо работает.
http://vapask.yandex.ru

Возможно это проще решить с NoSQL, но ОРМ должен быть поставлен под контроль, а именно под version control.

South разве не решает поставленную задачу?
Вап

Есть некоторые моменты, которые мне в Django непонятны. Например, почему в PositiveIntegerField можно записать отрицательное значение. Или почему иногда генерируется невалидный для некоторых баз запрос(например, подзапрос с LIMIT и OFFSET для MySQL будет неправильным). Поэтому в будущих релизах хотелось бы увидеть более полную и подробную документацию и уменьшение количества неочевидных вещей.
profiles.google.com/vlad.sirenko
Из коробки:
```
# aptitude install python-django
```
A не из коробки, те как сейчас:
```
$ hg clone https://bitbucket.org/wkornewald/django-nonrel
```
Ivan Sagalaev

Вряд ли Володя спрашивал про термин "из коробки". Рискну предположить, что речь о том, что поскольку термин "NoSQL" означает очень разные решения, что его невозможно "поддержать из коробки". Обычно люди под "NoSQL" подразумевают одну только MongoDB.
pySilver

Иван, поясните пжлста 2 момента:

сейчас Джанго не умеет real-time веб правильно, но тут WSGI не даст нам переделать архитектуру

Что подразумевается под real-time web? Чего не хватает в джанге?

Большая часть ядра Джанго, вообще-то, довольно неплоха. Да, у нас были определённые ошибки — например, валидация в моделях — но в целом всё хорошо.

Почему валидация в модели дурной тон?

Я всего пару месяцев работаю плотно с django, пришел из мира PHP (Zend Framework), неудобством для меня является некоторое упрощение абстракции в django т.е. view напрямую общается с моделями и менеджерами. Это упрощает разработку согласен, но для большого проекта лично мне непривычно общатся напрямую с ORM, при изменениях приходится менять 10 мест, вместо одного.

В Zend Framework я обычно строил Service Layer находящийся над Data Layer - валидация происходила именно в сервисном слое, вьюшки общались только с сервисным кодом. Грубо говоря Service Layer это бизнес логика, ему не интересно откуда пришел запрос и как хранятся данные, но он знает как их валидировать и интерпретировать.

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

Но пока что ни одного django проекта с Service Layer я не видел, и кажется мне это не спроста. Почему так не делают?
demiazz

Иван, так уж получилось, что не смотря на то, что работаю Django-разработчиком, но было время на близкое знакомство с Rails 3.

Очень интересно было бы узнать ваше мнение, как специалиста, довольно долго разрабатывавшего под Django, по поводу того, не стоит ли чего-нибудь заимствовать у столь быстро и резко развивающихся Rails 3? Я говорю не про прямое копирование функционала "в лоб", но вообще про взятие идей, и адаптации к Django.

P.S. Вопрос не холивара ради, как бы холиварно он не звучал.
Ivan Sagalaev

Этот вопрос тогда к вам, а не ко мне: я в Rails не смотрел :-).
Ivan Sagalaev

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

А про валидацию коротко не отвечу, потому что не знаю, что конкретно Рассел имел в виду. У меня к ней есть свои невнятные претензии, но речь не про меня… Постараюсь его порасспросить ещё :-).
oleg

Иван, а про переход Django на Python3, на DjangoCon, речь не заходила? Или про возможные планы?
Ivan Sagalaev

Заходила! Джейкоб выразился примерно так: "Когда речь заходит про Питон 3, люди обычно указывают на кого-то и говорят, что те их держат. Сначала это были драйверы БД, потом WSGI. Так вот теперь, если вы не заметили, все показывают на нас! Так что настало время наконец сделать это."

Ну и собственно: https://code.djangoproject.com/changeset/16742
Андрей Богомолов

Иван, по поводу ваших слов:

В теории должно мешать то, что Джанга рассчитана на работу в синхронной модели, а real-time серверы делают асинхронно обычно.

меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и сделать джангу асинхронной (правда с учетом всех багов гринлетов и того, что неблокирующими будут лишь операции с бд)

тот же вопрос иногда встает при сравнении twisted/tornado c stackless (почему все так тащаться от первых, когда второй выглядит намного удобнее для написания таких приложений), но это уже совсем другая тема...
Google user
После десятка проектов необходимыми и сложными в самостоятельной реализации фичами видятся следующие:
1. Нормальная интеграция модели с системой миграций, например South, лучше вообще включить его в Джангу. Гадать где там возникнет очередная проблема с наследованными классами моделей и т.д. несколько утомительно. Между разработчиками South и Django не хватает взаимодействия.
2. Нормальный механизм дампа и рекавера. Существующий написан левой пяткой никуда не годится. Дамп таблицы с 10.000 записей требует 8гб озу на борту, понятно почему, но непонятно почему это так. Зачем перегонят весь пирог через память? Без этого оснастки и весь связанный с ними механизм крайне ограничен.
3. Шаблонизатор бесшовно работающий как с локальными файлами, так и с шаблонами в базе.
4. Внятный менеджер конфигураций, ну хотя бы как в Tornado, только с возможность разделения конфига для разных приложений и сценариев. Все существующие решения слишком разношерстны и имеют свои проблемы.
Все эти вещи, на мой взгляд требует того, чтобы разработчики джанго взяли вопрос под свой контроль.

Ну и работа над ошибками и временными решениями, например удаление разночтений между поведением модели при операциях из админки и ручным управлением. Обнаруживать не сработавший ondelete крайне неприятно. Как и неприятно видеть, что творит ORM при удалении нескольких записей с внешними ключами. Я не люблю когда разработка превращается в танец с бубном и то, как ведет себя ORM при сколько ни будь сложнымх обращениях к нему - это прямая бубнозависимость. На маленьких проектах это не важно, на больших - принципиально.
Google user

меня всегда интересовало, почему никто не делает движений в сторону поддержки stackless или greenlets, ведь по идее насколько я знаю уже сейчас можно взять psycogreen и сделать джангу асинхронной (правда с учетом всех багов гринлетов и того, что неблокирующими будут лишь операции с бд)

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

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

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

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

Что будет при этом с 3-rd party страшно даже подумать. Даже в идеальном случае скорее всего получится маловразумительный клон джанги с крайне ограниченной функциональностью и сильно проигрывающий изначально асинхронным решениям. При этом очень непопулярный и редко используемый клон.

Если нужна асинхронка и неизбежно использование django, то лучше вывести колбеки на уровень непосредственно обработки, привязав их к какому ни будь асинхронному воркеру на twisted или tornado, который принимают, например, строку запроса к стороннему API и по завершению обращения дергают backurl с передачей ответа обратно в джангу. Если нужен, например, генератор тяжелых отчетов, то таким образом можно дернуть сторонний скрипт, подключенный к модели приложения.
Предок

чтобы на странице не писать кучу if-ов, а вставить {% check_perm app_name.view_name %}, и права проверялись именно те, что во вьюшке. (Пока что код просто дублируется.)

— oeuoeu, Иногда лучше почитать доку https://docs.djangoproject.com/en/dev/topics/auth/#id9

В Джанге, как раз, наоборот, вопрос распределения прав решен очень гибко и правильно, особенно пообъектное распределение прав. Не нравится писать бэкенды - подключи django-rules.

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

pySilver, - ответ на Ваш вопрос. Потому что Zend_Db_Table и близко не валялся с Джанго-ОРМ, потому его костылями и обвешивают. Более мудрые его вообще не используют, а интегрируют Доктрину.
Предок
Почему-то вспомнил http://lurkmore.ru/%D0%93%D0%BE%D0%B2%D0%BD%D0%BE%D0%BA%D0%BE%D0%B4

В Индии с некоторых времен существует практика оценки производительности труда программиста на основе количества написанного кода. Чем больше кода, тем больше программист работает, и, следовательно, выше его оклад. Шустрые индусы быстро сообразили, как обманывать неквалифицированных заказчиков. В результате чего можно встретить подобные шедевры (и это только цветочки!): [скрыть]
```
if (true) {
    // какой-то код
} else {
    // a вот тут чистый profit
}
```
Менее очевидный вариант:
```
if(var)
{
...
}
else if(!var)
{
...
}
else
{
// чистые деньги
}
```
Писать много кода - не проблема. Проблема писать мало кода. Очень распространенная проблема. написать лаконичную программу сложнее чем написать большую проблему. Идеал - это года нечего добавить, и нечего отнять.

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

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

— То же самое. Это поведение задокументировано (уж не буду тыкать ссылкой). Нужно внимательно читать доку. И для такого поведения есть обоснования.
Андрей Богомолов

Можно ли запустить джанго на торнаде или на стеклессе?

как можно ставить эти два решения в один ряд? торнадо - это как раз ближе к twsited.

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

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

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

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

Малореально полностью обернуть ОРМ в асинхронку

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

Nice write up, thanks for sharing.
Провёл анализ Django с версии 1.3 до версии 1.8

Провёл анализ рассылки Python Weekly? там часто можно встретить приложения.

Охват получился:

Django с версии 1.3 до версии 1.8

Что меня расстроило в 2011 году?

Тогда весь запад старался в Django использовать всё, что угодно кроме кода Django. Мне это очень не нравилось и я всё такие решил, что это не верный подход и решил для себя, что буду стараться решить всё при помощи чистого Django или Python.

Сейчас же в 2015 году (апрель), когда провёл анализ, запад отказался от идеи применения в Джанго принципа (использовать всё, кроме Джанго).

Все поняли, что сложности ни к чему и чистота кода, читаемось, лёгкость обновления превыше всего.

Это сильно порадовало.

Слова ДЖЕЙКОБА КАПЛАН-МОССА работают на практике, действительно в Джанго включается то, что хотят видеть пользователи. Это включение в 1,7 South, в 1,8 Джинжу.

Кстати, если посмотреть например вопросы и ответы Хабра, то явно видно, что рунет отстаёт в этом вопросе на те же 4 года.

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

Читать статью полностью здесь:

http://spb-tut.ru/guest/pages/47/