Что плохого в Django?

Ну, с другими продуктами на Питоне сравнить не могу, только на Django и писал, и то на уровне новичка. Но мне не понравилась многословность. Когда каждый чих требует массы ненужной писанины… Так что в результате Django у меня не прижилась. Ленив я для неё :)

И это я ещё с нуля писал, говорят, что как только дело доходит до адаптации Django к имеющимся моделям (неформатные имена таблиц, полей, JOIN'ы, нестандартные бэкенды), там всё ещё хуже становится. Но тут сам не пробовал, до этого не дошло :)

Скажут что жирно и вобще комбайн-велосипед. А что вместо спросят со стороны Django-баррикад:flask, например, ответят им. Но так каждый инструмент хорош под свои условия

Но мне не понравилась многословность.

Где именно?

Кому нужны были рельсы - те давно ушли на рельсы. А кому они и даром не упали, реализация «как рельсы, но не как рельсы» - не очень-то и нужна. Django - это модно, но кроме этого я не вижу особо, где она может понадобиться. Только если хардкорным питонщикам, которые раньше веба не касались, а потом решили уйти в веб.

Для python есть много разных, действительно разных фреймворков. Django просто самый модный из них, но другие решают задачи лучше. И проще.

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

Скажут что жирно и вобще комбайн-велосипед.

На самом деле, памяти ест копейки, и легко разбирается-собирается на компоненты.

Django просто самый модный из них, но другие решают задачи лучше. И проще.

Это какие же? Нет, серьёзно, просто примеры прошу, ругаться не буду.

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

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

http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Python

Список фреймворков. Здорово.

Где именно?

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

Ручные указания шаблонов

Class Based пользовать, не?

ORM там дубовая. Во многих PHP фреймворках ORM даже лучше.

Кстати, от себя могу добавить что расширение модели профиля пользователя не очень гибкое, на мой взгляд.

Какой-то дядя (по видимому неплохой кодер) считает, что проблемы процесса развертывания django-проекта сложнее среднего уровня

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

Да ничем. Просто это довольно монолитный фреймворк, а такое не по духу некоторым.

Если джанги не хватает для проекта, то перепиливать её сложнее, чем взять pyramid/flask/whatever и сделать всё на нём.

1. Унылый синтаксис шаблонов.

2. Унылая система загрузки шаблонов. Резолвер и лоадер зачем-то слеплены в одну сущность. Нет диспатчинга разным движкам.

3. До сих пор нет шотката для респонза.

4. В формах нет старого значения, нужно лисопедить самому.

5. Унылый ORM.

Статья, мягко говоря, удивила.
Чувак написал проект на Django, выложил его, а проект начал загибаться от 20 requests per second. Вместо того, чтобы выяснить где же проект нагибается и оптимизировать это место, он начинает нереально усложнять всю систему, и в конце концов повторяет инфраструктуру если не Google, то хотя бы какого-нибудь Disqus. После чего делается вывод: облачным хостерам жизненно необходимо помочь бедным индусам в развертывании крупных отказоустойчивых систем для того, чтобы индусы наконец-то смогли преодолеть барьер в 20 r/ps. Занавес. Авации.

До сих пор нет шотката для респонза

from django.shortcuts import render_to_response

В annoying че-то еще было.

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

Покажи код.

from django.shortcuts import render_to_response

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

Интересная статья. У чувака теперь ГОРИЗОНТАЛЬНОЕ МАСШТАБИРОВАНИЕ.

В annoying че-то еще было.

render_to. Вот это шоткат, а не то что разработчики джанги придумали.

Но это всё, по-сути, мелочи и на них можно забить, так как аналогов south и админки просто даже близко нет, они сильно облегчают разработку.

render_to. Вот это шоткат, а не то что разработчики джанги придумали.

Ага. Оно. Зато разработчики Джанги придумали class-based views, которые тоже могут здесь выручить.

А теперь приведи пример его использовани Шоткат, млин. Ню-ню.

render_to_response(«a_template.html», results)
A что, могло бы быть короче?

Мммм! Эксперты снова тестируют быстродействие HelloWorld'ов?

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

// «Что ж так неуклюже то всё?»

A что, могло бы быть короче?

Вот-вот, большинство джангистов только морковку и пробовали. А некоторым даже RequestContext не нужен (или не слышали о таком).

Мммм! Эксперты снова тестируют быстродействие HelloWorld'ов?

Эксперт, где ты там тестирование быстродействия увидел?

Кстати, зря я гундел. В 1.3, наконец, появился render. Лучше поздно, чем никогда.

Эксперт, где ты там тестирование быстродействия увидел?

Это собирательный образ эксперта, тестирующего whatever на ничего не делающей программке. Мозги включаем, да?

Помимо включения мозгов, неплохо бы еще глаза раззувать.

Странный у вас опыт, почему в джанго на каждый чих нужно много писанины? Джанга наоборот один из немногих фреймворков, который избавляет от ненужной писанины. Вы много видели фреймворков, которые в одну-две строчки по модели активируют административный интерфейс?

Да ты что? С учетом синтаксиса php , на нем противопоказано вообще писать ORM.

Вы много видели фреймворков, которые в одну-две строчки по модели активируют административный интерфейс?

Говорим «django» - подразумеваем «административный интерфейс». И вицыверса.

«Нашли, чем гордиться».

> Масса ручной работы там, где функции контроллера очевидны

libastral?

А если серьезно, то для этого есть generic views.

почему в джанго на каждый чих нужно много писанины?

Ну, я тут вчера начал понемногу (но в очень фоновом режиме) делать практический бенчмарк разных фреймворков. Простая задача, вывод странички из БД, с шаблоном, определяемым пользователем тэгом и т.п. Довольно долговременные планы, так что пока ничего не публикую, пока не сравню хотя бы 4..5 популярных фреймворков (а это значит, придётся в общих чертах разбираться с RoR, Grails, c JVM-фреймворками, возможно), но так как с Django, хоть и несколько лет назад опыт был, то с него и начал. Вышло (если выкинуть комментарии и html-шаблоны) в базовом (ещё не полном) варианте 4,5 кб. исходников. 121 строка длиннее трёх символов.

То, на чём я привык работать делает тот же тест в полном объёме за 900 байт и в 28 строк :)

И конечный вариант на Django будет ещё на десяток, наверное, строк больше.

Как оно будет на RoR или Grails пока без понятия, занимаюсь созданием этого теста в очень фоновом режиме, ещё Django не доделал (дофига всего забыть успел, оказывается).

man Class Based Views

С учетом синтаксиса php , на нем противопоказано вообще писать ORM.

Удивительное дело…

class PageDB(models.Model):
    url = models.CharField(max_length=200)
    title = models.CharField(max_length=200)
    html = models.TextField()

    class Meta:
        db_table = 'bft_pages'

<?php

class bft_pagedb extends bors_object_db
{
    var $db_name = 'TESTS_FRAMEWORKS';
    var $table_name = 'bft_pages';
    var $table_fields = array(
        'id',
        'url',
        'title',
        'html' => array('type' => 'text'),
    );
}

Неужели разница так фатальна? Ну, тогда можно на YAML (скорость будет даже быстрее, так как скомпилируется в кеш при первом обращении в более оптимальный функциональный вид):

table_name: bft_pages
table_fields:
    - id
    - url
    - title
    - html: text

man Class Based Views

Будет компактнее, чем:

def page(request, page_url):
    page = get_object_or_404(PageDB, url='/'+page_url)
    return direct_to_template(request, 'page.html', {
        'page': page,
    })

Да ты что? С учетом синтаксиса php , на нем противопоказано вообще писать ORM.

Тебе самому не противно, слепой ненавистник PHP? :)

(Юзал как SQLAlchemy, так и Doctrine.)

Удивительное дело…

Да не говори! Весело наблюдать ходячие наборы штампов и мифов. :)

слепой ненавистник PHP? :)

По сравнению с @deb'ом это просто поклонник PHP :) Он же его не поносит в каждом сообщении, также в каждое сообщение пихая bottle.py (на котором, что характерно, пишет также, как другие пишут на PHP :D)

Вот там — да, слепая незамутнённая PHP-ненависть.

А тут — просто один из штампов :)

А если серьезно, то для этого есть generic views.

Оно разве умеет автоматически связывать модель с представлением? Ну, то есть, загрузить без лишних указаний объект, связанный с view и подставить во view параметры этого объекта или хотя бы сам объект?

Можно пример?

Умеет, конечно. Примеры здесь:

https://docs.djangoproject.com/en/1.3/topics/class-based-views/#generic-views...

Будет в урлах как-то так:

url(r'^(?P<pk>[\d]+)/$',
        DetailView.as_view(model=my_model)
    )

Разница существенна. Как и читаемость кода, обратите внимание, на лаконичность и читаемость кода django ORM и перегруженность синтаксиса ORM написанного на php Что касается вашего примера на YAML, то наверное вам неведомо , что прелесть ORM и в том , что не нужно переключать контекст ))) Наверное поэтому разработчики django не стали внедрять такую фичу, чего проще ее было реализовать в django

Оно разве умеет автоматически связывать модель с представлением?

В Pyramid умеет. Называется это traversal. Жутко удобная вещь. Пример: http://docs.pylonsproject.org/projects/pyramid_tutorials/en/latest/humans/res...

Если вкратце, то процесс такой: создаем корневой объект (корень сайта), к нему цепляем потомки. У каждого потомка есть свои потомки. Строим обычный adjacency tree из Python-объектов.

Это все хранится в иерархическом словаре. Чтобы, например, получить объект (и впоследствии передать его автоматически в представление) для запроса /users/vasya-pupkin мы получаем элемент иерархического словаря примерно так: root['users']['vasya-pupkin']. Полученный объект отдается дальше, в представление.

Разница существенна

-- Мои глаза! О боже! Доллары, доллары у переменных!!!11

> Будет компактнее, чем:

там будет

DetailView(model=PageDB, url=url).as_view()

можно прямо в урлконф писать.