Django Micro

    В комментариях к посту Django as a Micro-Framework в блоге Ивана Сагалаева некий Andrew Pendleton выложил отличное решение для использования Джанго для микропроектов — djmicro.

    Внутри пример использования

    import djmicro
    djmicro.configure()
    
    from django.shortcuts import render
    
    @djmicro.route(r'^$')
    def hello(request):
        return render(request, 'index.html', {})
    
    @djmicro.route(r'^test/(\d+)/$')
    def test(request, id):
        return render(request, 'test.html', {'id': id})
    
    if __name__ == '__main__':
        djmicro.run()
    


    А запускаем это все командой

    python web.py runserver
    


    Ну и кому интересно может ознакомиться с исходным кодом
    github.com/apendleton/djmicro/blob/master/djmicro.py
    Share post

    Comments 100

      +7
      Очень flask'о подобно как-то :)

      Да и я не понимаю, зачем использовать джангу для микро преоктов? Возьмите flask и т.п.
        +3
        Привычка, например.
        Нет желания переходить на SQLAlchemy + Jinja.
          0
          это ж как нужно себя нелюбить, чтобы использовать Django ORM. Для домашней странички оно пойдет, а вот сложные запросы будете постоянно писать с помощью костылей(RAW SQL)?
          0
          Микропроект хочется сделать быстро, не изучая новый фреймворк для этого. Кроме того, есть шанс, что проект будет развиваться и станет полноценным сайтом.
          +4
          Да это же Flask! :)

          Вообще, если надо быстро/микро — берём Flask. Не ленимся, тратим пару часов на чтение SQLAlchemy или MongoAlchemy, если нужны формы — WTForms (ещё пол-часа времени на доки). Jinja2 будет как дом родной для тех, кто на ты с шаблонизатором Django, (я вот лично полюбил макросы, вкусно). Да и быстрее всё в разы. Мало того, во Flask есть те же class-based views, хоть и в упрощённом варианте, есть полезный и быстро растущий набор расширений… Короче стрельба из пушки по воробьям. Разве что ради Django ORM, но, опять же, есть варианты.
            +1
            Тут все из коробки )
            Плюсом — миддлваре, кеши и прочие вкусности.
              0
              Извините, но миддлвари во фласке реализуются раз в 10 проще, чем в Джанге. А еще во Флеске есть кэш их коробки и вообще множество вкусностей. Фласк — он вовсе не микро, как многие думают, он как айсберг.
                0
                Спасибо, будет время — посмотрю подробнее.
              0
              Но не спорю — кому то удобнее Flask.
                0
                Всё ж от задачи зависит. Странно для сайтов-визиток задействовать Django и странно писать большие сайты-приложения на Flask.
                  +1
                  Ну вот у меня было пару сайтов визиток на джанго с одним единственным app.
                  Теперь будут на djmicro.
                    0
                    > странно писать большие сайты-приложения на Flask

                    почему?
                    как раз-таки для большей гибкости и максимальной производильности лучше вместо джанговского ORM использовать sqlalchemy / mongo и jinja2
                      0
                      Давайте холивар разводить не будем. Решения что в плане ORM-а и в плане шаблонов практически идентичны. Что по функционалу, что по скорости.
                      А то из вашего комментария следует неверный вывод о том что джанговский орм и шаблонизатор медленный и ужасно монолитный.
                      Тут 100% вопрос привычки.
                        0
                        просто не понимаю почему для Flask странно писать большие сайты? в чем причина?

                        p.s.
                        orm и шаблоны как раз-таки отличаются еще как ) но не будем об этом.
                          0
                          У меня за всё время работы с Django ORM появилась только одна претензия — это невозможность параметризировать аннотацию. А вот Jinja2 даже визуально быстрее отрабатывает. Хотя нет темплейт-тегов (но можно вырулить другими средствами).
                            0
                            Jinja2 раз в десять быстрее. Тестировал во времена django 1.2. Правда, существует кеширование шаблонов. Не знаю, как оно повлияет на скорость.
                              0
                              ну кэширование все равно не поможет если например нужно отослать какую-нибудь почтовую рассылку где надо отрендерить несколько млн. писем :)
                          0
                          Flask сложно поддерживать структурно при разрастании проекта. Вот сейчас я и провожу такой эксперимент, пишу сайт на Flask+MongoAlchemy+всякое. Как побочный продукт родился Flask Kit, с которым всё несколько удобнее, если сайт — это не один единственный application. Я его запилил на GitHub, но не особо афиширую, так как не могу выкроить время на написание полноценной документации.
                            0
                            ничего сложного, мы написали очень большой проект (соц. сеть) на Flask и не столкнулись с какими-либо проблемами
                              0
                              Ссылку, please. И было бы очень круто на код хоть одним глазком… случаем, не заопенсорсили хоть что-нибудь?
                                0
                                gidepark.ru

                                код закрытый
                        • UFO just landed and posted this here
                            +1
                            Ну джангеры кстати лицемерно выступают против, стыдливо умалчивая про внутренности ORM — connection же передается как раз по фласкерски. Только flask это не только thread locals, но и поддержка greenlet
                            Поэтому манкипатчолл во фласке то сработает, а в джанге нет.
                        +2
                        > Вообще, если надо быстро/микро — берём Flask. Не ленимся, тратим пару часов на чтение

                        :-)
                          +1
                          Ну, если так говорить, то проще взять джангу ;)
                          +2
                          django хорош своими батарейками, и тут уж или использовать все,
                          или брать Flask+sqlalchemy/mongo+jinja2+wtforms.
                          не вижу смысла в djmicro
                            +3
                            Такой проект можно легко превратить его в полноценную инсталляцию Django, если это зачем-то понадобилось.
                            +3
                            А мне это напомнило новый и очень удобный микрофреймворк bottlepy.
                              0
                              Очень новый.
                              0
                              А мне понравился djmicro, Уже придумал, где его использовать.
                                –1
                                Черт. За три месяца изучения Django и Python практически с нуля, я написал достаточно сложное и навороченное приложение (для интранета). И уже начал думать, что неплохо освоил Django. Ну, исходя из того, что для реализации подобной задачи на голом PHP потребовалось бы точно больше года. :)

                                Но я почти ничего не понял из того что вы все тут понаписали выше в комментариях. %)

                                К чему я это все написал… Посоветуйте, пожалуйста, годную литературу по Django. Можно без раздела «Ваше первое приложение», но с описанием лучших практик создания сложных приложений, объяснением, куда копать, если не хватает производительности и т.п. В общем, что-то для уровня выше среднего.
                                  +1
                                  Все книги из разряда «Напишите свой первый блог в 30 строк кода»
                                  Но читать djangobook конечно в первую очередь.
                                  А так — рекомендую вписаться к более опытным товарищам в проект. Увидишь кучу хорошего кода и правильных архитектурных решений.
                                    0
                                    В Django Book я периодически заглядываю по мере возникновения вопросов (на просто нередко нагугливается на первую страницу выдачи по многим популярным запросам), но она ведь несколько устарела, не?
                                      0
                                      Да, но прочесть начинающим стоит в любом случае.
                                      0
                                      Смотря, что за проект. Практика показывает, что есть неиллюзорные шансы найти кучу костылей и говнокода, написанных несколько лет назад человеком, которого и в проекте то уже нету :)
                                        0
                                        Разумеется. А кто говорит что будет легко? )
                                    0
                                    а если допилить до такой конструкции
                                    from django.views.generic.simple import direct_to_template
                                    @djmicro.route(r'^lalala/$', direct_to_template, {'template': 'lalala.html'})
                                    то вообще можно будет без вьюх обойтись
                                      –1
                                      посмотрел исходный код, поидее сработает и без допиливания
                                        0
                                        Декоратор без декорируемой функции? Оригинально.
                                          0
                                          я имел ввиду что то, что внутри @djmicro.route приаттачится к оригинальному urls со всеми аргументами, т.е. можно еще сократить код. хотя практического смысла в этом нету.
                                            0
                                            Смысл есть, хотя бы для рендеринга переменных, входящих в контекст. Как писал ниже, например данных авторизации.

                                            Ваш код же должен выглядеть как-то так
                                            djmicro.route(r'^lalala/$', template='lalala.html')(direct_to_template)
                                            
                                        +1
                                        А еще можно lalala.html через nginx отдавать :-)
                                        Вьюха, вроде бы, нужна, чтобы какие-то данные там достать/обработать и передать в шаблон…
                                          0
                                          Ну вообще-то direct_to_template рендерит шаблон включая контекст, а не просто отдает html.
                                          Юзернейм, например, Вы как собираетесь в nginx-е отображать?
                                            0
                                            Юзернейм предполагает авторизацию. Авторизация нужна для какой-то активности пользователя на сайте. Активность предполагает обработку во view.

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

                                        Когда я разрабатываю миниприложение, то разворачивать Джангу мне кажется делом долгим и утомительным. К тому же, архитектура Джанги этому не способствует — у нас есть проект, в котором должно быть приложение. Зачем, когда некоторые приложения можно целиком уместить в один файл, как во Фласке?

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

                                        Разбираясь со Фласком, я познакомился с расширениями для админки, авторизации. Например, авторизация во Фласке позволяет самому задавать класс пользователя. Получается, что практически все возможности Джанги покрыты, а система гораздо гибче.
                                          0
                                          можно плз подробнее про расширения для админки? что-то мы смотрели (давно правда) несколько и на тот момент мало что устроило, вдруг что допилили уже )
                                            0
                                            Там все очень просто, до уровня Джанги не дотягивает, конечно, но Create, Edit и Delete работают. Что еще надо?
                                            Указываете, какие модели отслеживать в админке. Можно указать свои формы, если генерируемые по-умолчанию не устраивают. Создаете админский блюпринт и подключаете к приложению.
                                            Чего не хватает — так это поиска по указанным полям.
                                              0
                                              Допишу, что поддерживаются связанные поля, т.е. ссылки на другие модели.
                                              Скрин админки
                                            +3
                                            Надо же, как странно, а мы наоборот, благодаря Джанге сэкономили кучу времени…

                                            90% всех претензий Джанги (а из перечисленных Вами наверное 99%) — это проблема не Джанги, а уровня разработчиков.

                                            Типичные обвинения типа «ОРМ» и «Шаблонизатор» звучат со стороны тех, кто ни разу не открывал исходников Джанги. И почему-то умалчивается тот факт, что 90% синтаксиса Jinja — это синтаксис Django. И почему?

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

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

                                            ОРМ Джанги — обычно критикуется зря. Есть костность QuerySet (а не ORM), но эта проблема решаема. Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy.

                                            Лично я одинаково отношусь и к Flask, и к Django, и к Svarga (жаль что забросили), и к wep.py (не путать с wep2py), и к Pyramid, и к Plone, и к CherryPy, и к bottle, и к TurboGear…

                                            Но когда проект большой, и «один в поле не воин», тогда Джанго — хороший инструмент. Один только djangopackages.com/ чего стоит… Есть причины, по которым такого «окружения» нет у других фреймверков. Именно причины, а не недостатки. Там где начинается много гибкости, — там обычно заканчивается много унифицированности.

                                            > В других приложениях мне не подошла Джанговоская авторизация и модель юзера. У нас все было завязано на номер сотового телефона — его приходилось хранить в профиле, что было очень не удобно.

                                            — есть масса способов не хранить телефон в профайле, а хранить его в юзере…

                                            > не подошла Джанговоская авторизация

                                            — Авторизация, или аутентификация? Скорее всего аутентификация. Сложно представить ситуацию, когда система аутентификации Джанги может не подойти… по крайней мере, судя по этому github.com/omab/django-social-auth А чтобы интерфейс авторизации не подошел, — еще сложнее верится, опять же, судя по этому djangopackages.com/grids/g/perms/

                                            > Например, авторизация во Фласке позволяет самому задавать класс пользователя.

                                            — setattr(model, 'ClassName', NewUser) тоже позволяет… Но в Вашем случае хватило бы Field.contribute_to_class()

                                            > Получается, что практически все возможности Джанги покрыты, а система гораздо гибче.

                                            — гм… Ну, Flask, вообще-то, хорошая система… мне нравится, по крайней мере… Просто сравнение не совсем корректное…
                                              0
                                              > При этом обвинения в сторону производительности шаблонизатора звучат с уст тех, кто ни разу не разрабатывал проекта с посещаемостью более 1000 уник. в сутки…

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

                                              > Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy

                                              можно плз подробнее?

                                              > есть масса способов не хранить телефон в профайле, а хранить его в юзере…

                                              тоже поясните плз как вы делали?
                                                0
                                                > не хранить телефон в профайле, а хранить его в юзере… тоже поясните плз как вы делали?

                                                — уже сказал, setattr(model, 'ClassName', NewUser) или Field.contribute_to_class() (или Model.add_to_class())

                                                Пример как перебить объект в модуле — bitbucket.org/carljm/django-localeurl/src/48e3391e3197/localeurl/models.py только там функция вместо объекта.

                                                > Есть множество способов решить этот вопрос. И даже без raw и extra… SQL в строчном виде. А высокоуровневыми средствами. И не обязательно даже SQLAlchemy… можно плз подробнее?

                                                1. habrahabr.ru/blogs/python/128052/
                                                2. Объявлять модели через свою фабрику, как сделано bitbucket.org/deepwalker/amalgam
                                                3. Использовать SQLBuilder от SQLObject, StormORM, SQLAlchemy, py-smart-sql-constructor и т.п. для создания SQL, и затем подставлять его в Manager.raw(). Там нужно будет решить несколько нюансов, но они решаемы. И даже связи у результата запроса (инстанции модели) подхватываются.

                                                > а jinja2 генериться млн. писем будет гораздо быстрее

                                                — А Вам нужно каждый раз читать и парсить шаблон? Редко бывает, что пути поиска шаблонов в процессе работы скрипта меняются. Всего 5 строчек кода, — и шаблон только единожды прочтётся и распарсится, а затем будет просто реднериться. Потом можете и замеры делать…
                                                  0
                                                  > setattr(model, 'ClassName', NewUser) или Field.contribute_to_class() (или Model.add_to_class())

                                                  в прошлом проекте у нас был Model.add_to_class(),
                                                  в итоге этих строчек было очень много, тут же еще и методы надо добавлять таким способом, это смотрится как-то совсем ужасно, это совсем не python-way.

                                                  > 1. 2. 3.
                                                  как-то все это костыльно, да и паттерны-то отличаются, у алхимии Data mapper.
                                                  мне интересно можно ли поймать event между получением данных из базы и созданием model instances чтобы добавить к model instances дополнительное поле которое не объявлено никак, а данные для этого поля приходят из дополнительного генерируемого поля в query.
                                                  например нам нужно вывести дерево комментариев одним запросом через WITH RECURSIVE ..., level и прочее для комментариев в базе не хранятся, чтобы дерево не пересчитывалось долго (а когда комментариев очень много, то пересчет долгий), level считается на лету, и нам нужно подсчитанный level добавить в инстанс модели.

                                                  > шаблон только единожды прочтётся и распарсится, а затем будет просто реднериться

                                                  ну так сам рендер и медленный же.
                                                    0
                                                    > ну так сам рендер и медленный же.

                                                    — цифры?
                                                      0
                                                      сейчас я сам тест писать не буду, не до этого.
                                                      раньше проверял, была разница.

                                                      ну а так есть в сети же тесты тоже

                                                      www.askthepony.com/blog/2011/07/django-and-postgresql-improving-the-performance-with-no-effort-and-no-code/

                                                      stackoverflow.com/questions/8318999/why-isnt-this-jinja2-template-rendering-faster-than-djangos

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

                                                        Плюс эти спидапсы даже в GAE запилены, специально под джинджу.
                                                        0
                                                        > мне интересно можно ли поймать event между получением данных из базы и созданием model instances чтобы добавить к model instances дополнительное поле которое не объявлено никак, а данные для этого поля

                                                        QuerySet.iterator если на низком уровне.
                                                        Или добавить свой метод get_comments_with_level
                                                          0
                                                          хм, пока не представляю как это можно сделать в джанге без костылей.

                                                          iterator() возвращает просто сырые данные? т.е. инстансы моделей нам самим создавать и заполнять?

                                                          > get_comments_with_level

                                                          вопрос как заполнять эти дополнительные поля, проходиться отдельным циклом по данным это не айс :)

                                                            0
                                                            хм, пока не представляю как это можно сделать в джанге без костылей.
                                                            Каких костылей?
                                                            Пишите свой Manager в котором указываете метод get_queryset
                                                                def get_query_set(self):
                                                                    """Returns a new QuerySet object.  Subclasses can override this method
                                                                    to easily customize the behavior of the Manager.
                                                                    """
                                                                    return QuerySet(self.model, using=self._db)
                                                            


                                                            iterator() возвращает просто сырые данные? т.е. инстансы моделей нам самим создавать и заполнять?
                                                            Он возвращает инстанс модели.
                                                            code.djangoproject.com/browser/django/trunk/django/db/models/query.py#L231

                                                            вопрос как заполнять эти дополнительные поля, проходиться отдельным циклом по данным это не айс :)
                                                            Ничего не понимаю. Вы сейчас говорите о недостатке какого-то конкретного решения, которое сами придумали для джанги и осуждаете?
                                                            Почему алгоритм который не будет проходить отдельным циклом будет работать где-то еще а не будет в джанге? Вам не кажется что вы сейчас черезчур субьективно рассуждаете.
                                                              0
                                                              ну что поделать, у меня есть конкретная задача, и к сожалению данное решение мне не подходит.
                                                                0
                                                                Да ладно, просто признайте что не хуже SQLAlchemy )
                                                                  0
                                                                  если бы был данный event (что возможно когда-нибудь добавят в будущем), то да, а так нет
                                                                    0
                                                                    В критической ситуации (правда Ваша ситуация совсем не критическая) — всегда можно использовать библиотеки для AOP программирования. На Питоне их несколько, — можно выбрать по вкусу.
                                                                    0
                                                                    и это еще несмотря на то что джанга в принципе такой запрос сгенерировать не сможет и придется писать ручками
                                                                      0
                                                                      1. Какой такой?
                                                                      2. В чем проблема написать SQL?
                                                                        0
                                                                        with recursive, в итоге должно получаться что-то подобное pastebin.com/Aa1z0i9k

                                                                        для алхимии есть готовый extension
                                                            +1
                                                            > как-то все это костыльно, да и паттерны-то отличаются, у алхимии Data mapper.

                                                            Почему костыли? Причина? Только в том что используется другой SQLBuilder?

                                                            В SQLObject он полностью автономный, не зависит от ORM, легко отделяется от библиотеки, — всего три файла. С точки зрения Архитектуры — никаких костылей (и жаль что вы чистое архитектурное решение назвали костылем, это впрочем, о многом говорит). У Вас просто в проекте 2 SQLBuilder, — один простой, но зато удобный. Второй гибкий, для сложных SQL-запросов.

                                                            > да и паттерны-то отличаются, у алхимии Data mapper.

                                                            — Дорогой Lestat, не могли бы Вы пояснить, как связаны SQLBuilder и ORM? И какое отношение к SQLBuilder имеет «event между получением данных из базы и созданием model instances»?

                                                            Вы либо используете один, и только один ОРМ, независимо от того, чем строите SQL, либо у Вас в проекте два самостоятельных ОРМ, но с общими схемами.

                                                            > в итоге этих строчек было очень много

                                                            — Можно подробнее? Где именно, на каких таких моделях получилось много строчек? Всего на одной модели User? Какие еще модели?

                                                            Не нравится Field.contribute_to_class(), используйте setattr(), чтобы код был чистым. Или вообще, — весь файл перепишите по своему, и укажите где модуль должен его искать docs.python.org/tutorial/modules.html#packages-in-multiple-directories

                                                            Абсолютно не вижу проблем в таком языке программирования как Питон, если в нем конечно хоть немного разбираться…
                                                              0
                                                              > два самостоятельных ОРМ

                                                              не, не надо нам такого счастья )

                                                              > Всего на одной модели User?

                                                              да, на ней самой
                                                              +1
                                                              > например нам нужно вывести дерево комментариев одним запросом через WITH RECURSIVE ..., level и прочее для комментариев в базе не хранятся, чтобы дерево не пересчитывалось долго (а когда комментариев очень много, то пересчет долгий), level считается на лету, и нам нужно подсчитанный level добавить в инстанс модели.

                                                              — Этот вопрос немного из другой области. Тут нужно просто выбрать верный способ хранения дерева. Благо в Джанге вопрос работы с деревьями хорошо решен:

                                                              github.com/django-mptt/django-mptt
                                                              bitbucket.org/tabo/django-treebeard
                                                              bitbucket.org/fivethreeo/django-easytree

                                                              Причем, если выбирать NS, — то можно на каждую ветку делать свое дерево. А больших веток не бывает, — т.е. тормоза NS вы не почувствуете. Ну или MP. Кстати в github.com/HonzaKral/django-threadedcomments как раз MP и используется, если не ошибаюсь (в последней версии).
                                                              0
                                                              > Пример как перебить объект в модуле…
                                                              Извините, но меня смущает такой подход. Я хочу, чтобы у меня была «чистая» модель безо всяких шаманств. И расширение flask-login вообще крайне лояльно относится к классу пользователя, оно лишь требует, чтобы у класса было всего 4 метода, которые добавляются mixin-ом. Сразу видно, что разработчик не пытался домыслить за остальных, что им нужно, а просто продумал гибкую архитектуру.
                                                                +1
                                                                Ну если Вам легче сменить фреймверк, нежели использовать штатные средства языка программирования (даже не фреймверка) — то это Ваше личное дело. Причем тут Джанго?

                                                                Правда последние Ваши слова немного не согласуются с первыми:

                                                                > «В других приложениях мне не подошла Джанговоская авторизация и модель юзера. У нас все было завязано на номер сотового телефона — его приходилось хранить в профиле, что было очень не удобно.»

                                                                Как выяснилось, Джанго Вас ни в чем не ограничивало. И вопрос не в ней, а в способности разбираться с вопросом. Иначе инструментов не напасешься…

                                                                Лично я когда использую Flask, — то причина не в том, что Django плохая. Я понимаю, что сегодня модно плюнуть в сторону PHP, Django и т.д., и таким образом лишний раз утвердиться. Я с одинаковым комфортом могу работать как в Django так и во Flask. И выбираю их исходя из того, что лучше подходит под задачу.

                                                                Если я делаю, например, социальную сеть, и для Джанги я могу найти готового кода на 8 человеко*месяцев, — то я выбираю Джанго. Даже если и будет несколько костылей (но это отнюдь не то, что вы назвали костылями)
                                                                  0
                                                                  Учитывая количество современных языков и фреймворков, можно утверждать, что сегодня выбор фреймворка носит исключительно личностный характер. По сути, разработчик ощупывает разные технологии, прислушиваясь к ощущениям — что лучше ложится на мозги, что легче осмыслить. Для себя я выяснил, что лучше работать с нормально построенной моделью пользователя. В этом смысле меня ограничивает Джанга — ваш вариант скрывает ясность процесса, что противоречит известным принципам в питоне.
                                                                    +1
                                                                    8 и 9 принципы философии Питона гласят:

                                                                    8. Особые случаи не настолько особые, чтобы нарушать правила.
                                                                    9. При этом практичность важнее безупречности.

                                                                    Так что это еще вопрос, что больше противоречит…
                                                        0
                                                        Я непонимаю что подразумевается под микропроектами. Если взять туже сайт визитку, то там нужна админка, менюхи, страницы, генерация урлов, разные блоки, аплоэд файлов, формы и т.п. Это довольно быстро решается с помощью батареек. А если все это писать самому в одном файле, то будет потрачено очень много времени. Если речь идет о сайтах-заглушках, там и вовсе питон не нужен, выложил html файлы и все.
                                                        То что на микрофреймворке все быстрее в разы, дак это вообще не аргумент. У джанги скорость достаточная как для визиток так и для highload. И что такого «долгого и утомительного» в разворавичании джанги мне тоже непонятно.
                                                          +2
                                                          Визитка — это не всегда микропроект. То, что вы описали — это явно не «микро». Микропроектом можно назвать приложение, которое имеет всего один обработчик. Например, интерфейс для взаимодействия с платежными системами. Такое приложение принимает запрос и возвращает XML-документ. Всё приложение умещается в один файл на 100-150 строк.
                                                          0
                                                          вообще к чему все это, я пытаюсь донести что не единой джангой в питоне можно жить.

                                                          джанга хороша для 90% случаев, но это не значит что в остальных 10% надо пытаться подогнать ее под работу.

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

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

                                                            Опять же фласк и джанго это инструмент. Каждый его использует как хочет. Вот для джанги появилась возможность упростить кое-что благодаря djmicro. Я об этом написал.
                                                            В ответ прилетело 100500 комментариев что нужно использовать SQLAlchemy, что Jinja быстрее итд.

                                                            Еще раз говорю — у меня все проекты на джанго. У меня она стоит везде. Я знаю все ее плюсы, минусы, баги и прочие вещи, потому что я ее использую уже с времен когда она была 0.х.
                                                            Я могу решить на ней абсолютно любые задачи, которые решаемы на Flask/Jinja/SQLAlchemy и прочих.
                                                            Зачем мне тратить свое время на незнакомый для меня инструмент?

                                                            PS Вариант «изучить что-то новое» не вариант, потому что я в данном контексте сейчас смотрю на Haml и coffescript. Как появится время думаю взглянуть на скалу, objective C и хаскелл.
                                                              0
                                                              Но шутки в сторону. Скажите мне замшелые троглодиты из реально нереально серьезной веб разработки, что, экономия на рендере шаблонов это лишнее для проектов с посещаемостью >1000? Более быстрая разработка с более гибким ORM это лишнее? Да вы вообще БД используете, или планируете проект на sqlite запускать в продакшн? Даже обработка URL в Werkzeug быстрее. Можно говорить что где-то это копейки, но когда все копейки собираются во Flask, это уже становится серьезно, мимо проходить уже как-то непрофессионально, и даже как-то стыдно.

                                                              Полная версия ответа:

                                                              deepwalker.blogspot.com/2012/03/django-web.html
                                                                0
                                                                Михаил, я не хочу с тобой спорить, потому что знаю что ты серьезный специалист, и говоришь всегда то что есть на самом деле.

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

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

                                                                Что касается "… когда все копейки собираются во Flask, это уже становится серьезно...", — то могу сказать, только одно, и, думаю, ты со мной согласишься. В подавляющем большинстве проектов, шаблонизатор и обработчик URL влияют на производительность в наименьшей степени. Как правило, в средне-статистическом проекте такое количество пожирателей ресурсов, что хоть на Ассемблер переписывай эту логику, — сайт быстрее работать не станет. И если уж и говорить про вопросы быстродействия и оптимизации, — то заходить надо с другой стороны.

                                                                Если уж заниматься производительностью, — то ей нужно заниматься серьезно. Это как раз та область, где уровень квалификации разработчика играет более весомую роль, нежели скоростные показатели фреймверка. А когда не совсем квалифицированные разработчики сводят свою борьбу за производительность к тому, чтобы покритиковать Джангу, то это просто удовлетворение самолюбия, и ничего общего к Джанге не имеет…
                                                                  +1
                                                                  Sqlalchemy и разработка на django orm под sqlite — использование возможностей хорошей БД типа postgres это спички? Django ORM даже куцый sqlite не покрывает.
                                                                  Невозможность использовать gevent в django спички?

                                                                  Классическое приложение это выборка данных из базы и форматирование их в страницу — все эти вещи во flask будут сильно быстрее и проще в использовании. Это экономит время на разработку, это экономит затраты на функционирование сервиса в облаке — use less to do more.

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

                                                                  Это источник другого взгляда на разработку. Но в общем что-то опять пост получается, закруглим.
                                                                    +1
                                                                    Я вот одного не пойму — что у вас за батхерт за такой, что Вы с пеной у рта доказываете другим как надо жить?
                                                                    Обычно подобный максимализм свойственен юношам лет 18-20, у которых гормоны еще играют.
                                                                      +1
                                                                      Этот прием использовали девочки в годы школьные — ну пацаны, ну шо вы как мальчишки, вам же по 14 лет уже!!! Где вы таки детектировали пену? В комменте про «я пишу на джанге 10 лет, и за 10 лет не освоил ни одной новой технологии»?
                                                                  0
                                                                  Экономия на рендере шаблонов, урлах и т д — ну смешно же. Поднимем еще пару нод на s3, проблем-то.

                                                                  Куда важнее, что пока в Виллариба пишут очередной компрессор css-файлов/цмс/crud для древовидных структур/авторизацию, в Виллабаджо уже сдали проект.

                                                                  Да, общее качество кода в джанго-проектах в pypi оставляет желать лучшего (не лютый ад типа phpclasses.org конечно, но все же). Да, dependency hell. Зато как приятно, когда 70% проекта находится в requirements.txt

                                                                  P.S: сейчас перетягиваем кусок проекта на торнадо. джанга не вытягивает, ага, оверхед большой. но большую часть кода это вообще никак не затронет. работает — и славненько
                                                                    0
                                                                    Экономия это приятный бонус, разработка на flask проще. Компрессор есть, какая-то админка есть. Есть альтернативный ORM pewee некий — там с админкой и тп, комплектом, но сам я не смотрел, ибо не понял в чем преимущество перед sqla.
                                                                    В общем Flask он не пустынен, requirements там вполне себе обширный выходит. Так что Виллабаджо замучается пыль глотать.
                                                                      0
                                                                      у pewee преимуществ перед sqla как раз таки-нету, если сравнивать объективно и по всем показателям
                                                                        0
                                                                        и кстати, при всей возне никто не рассматривает конкурентом pyramid — интересно — почему бы это? В нем конечно не jinja из коробки, а скорее Mako — синтаксис которой оставляет желать лучшего, но это всё опционально и заменяемо :)
                                                                        И кстати — приложение в виде одного файла реализуется так же просто как и во Flask
                                                                          0
                                                                          Ну начинается, эта мне оппозиция, вечно растекаются по кандидатам. Суть же в протестном голосовании, чтобы джанго не ушла на второй проект. А Flask выбран как единый кандидат :)
                                                                            0
                                                                            а я вот всерьез рассматриваю пирамиду как опцию с возможностью автогенерации ресурсных урлов, если сейчас еще окажется, что там отдача контента следует RESTful нотации, то плакал ваш Flask далеко позади (и да, в pyramid sqla уже есть). У меня сейчас на той же задаче крутится tornado, скорость и удобство разработки под который заставляет — хм, много думать об альтернативных вариантах.
                                                                              0
                                                                              Черт, придется таки поставить пирамиду и попинать. Умеете убеждать, товарищ.
                                                                                0
                                                                                а я хотел поглядеть торнадо )

                                                                                а в чем проблемы с ним?
                                                                                  0
                                                                                  Проблем-то как раз нет, но местами возникают вопросы — а нужна ли асинхронность при последовательном ожидании результата из data-storage. Когда следующая операция зависит от предыдущей и приходится ожидать.
                                                                                  Лапши колбэков, увы, тоже нету, @gen.engine + gen.Task спасает всё же.
                                                                                  Сейчас уже есть пара мыслей как это «правильно» реализовать с учетом websocket и некоторого времени, прошедшего со старта разработки.
                                                                                    0
                                                                                    Просматривал другой топик, и подвернулась удачная фраза, которая как нельзя лучше описывает процесс выбора фреймверка:

                                                                                    > В общем «Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколь-нибудь развязанное, какая у Балтазара Балтазаровича, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась. А теперь — поди подумай!»
                                                                                      0
                                                                                      вроде есть же асинхронные драйверы для postgresql/mysql/etc? или тут не прокатывают?
                                                                                        0
                                                                                        Всё правильно, асинхронные драйверы есть. Суть в том, что они тоже любят callback одним из аргументов — решение, как я уже говорил — использовать tornado.gen, но если идёт обработка нескольких зависимых сетов — толку от асинхронности — ноль по вдоль.
                                                                                          0
                                                                                          Не совсем понял суть проблемы..., можно же вместо callback использовать deferred объекты, и когда завершатся несколько параллельных зависимых операций — идти дальше… ??

                                                                                          Где-то я даже встречал, что кто-то вырезал deferred из twisted, вроде эта ссылка github.com/mikeal/deferred там и цепочки можно создавать… и списки запускать… и ожидать результата пока требуемые процессы завершатся…

                                                                                          Хотя… вот тут вроде что-то похожее написано… www.tornadoweb.org/documentation/gen.html
                                                                                  0
                                                                                  Ну вот он этот «протестный» принцип успешно и применяет… Как говорится, не рой яму другому…
                                                                                    0
                                                                                    Это дружеские подколки.
                                                                                      0
                                                                                      Да понятно..)
                                                                        0
                                                                        Ха, вот уж не думал… От создателя Flask (Armin Ronacher), — всеми ругаемый Django QuerySet для SQLAlchemy…
                                                                        github.com/mitsuhiko/sqlalchemy-django-query
                                                                        даже не знаю, что сказать…

                                                                        Only users with full accounts can post comments. Log in, please.