[Насиловать труп] Re: Вышел web.py 0.3

Из лёгких веб-фреймворков лучше всех Werkzeug. Только никто не может осилить название, вот и не пользуются. Это не шутка.

True.

Веркцойг наше все.

> print заменен на return, что привело к несовместимости с версией 0.22

Я один не понимаю - как нужно было писать, чтобы print и return можно
было заменить?

webpy тоже ничего. с вебом не работаю, но несколько простых страничек на нем делал - очень удобно! веркцойг посмотрю, спасибо

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

Я не очень много им пользуюсь, но дома на NSLU2 крутится несколько полезных вещей. Для этого web.py рулит.

Посмотрел сейчас на Werkzeug - мне понравилось. В целом у них близкая идеология, так что выбор по вкусу, но к web.py я уже привык. Ну и Hello World на web.py покороче будет :)

а я вот пока и Pylons считаю достаточно "лёгким" :) Пробовать что то ещё пока не тянет....

Да. Hello world впечатлил.

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

Мой выбор сегодня: sqlalchemy, jinja2, babel и werkzeug.

Ах да, забыл еще FormEncode.

>несовместимая со старой

питонщики в своём стиле, ага))

прочитал как веб.ру вместо веб.пи, наверно нада лечиццо

Капча "Родили"(roodily) помойму полностью описывает состоянине нынешнего софтпрома:)

>>несовместимая со старой

>питонщики в своём стиле, ага))

Скорее это явисты в своем.

Я как бы догадался...:))
Я написал это к тому, что если ты вызываешь какой-то объект, то
ничего никуда он печатать не должен. Он может только возвратить
тебе какие-то данные. Иначе теряется вся логика ООП.
Т.е. писать с использованием print идиотизм с самого начала...:))
Рад, что разработчики вовремя одумались...:)

Nanoc наше фсио!

документация на сайте:

>> Поддержка URL

>> Самая важная часть \\\\любова//// файла это структура его URL.

и так далее...

Никто не заставляет переходить на версию 0.3, но в любом случае переход будет достаточно простым. А то что в проекте появляются новые идеи - это очень хорошо.

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

и ещё постоянные "Преведы" в документации порядком раздражают. Как-будто на каком-то удафф-коме находишься.

>и ещё постоянные "Преведы" в документации порядком раздражают. Как-будто на каком-то удафф-коме находишься

читай на английском или кто-то мешает?

Неделю назад начал писать небольшой проект. Из питоновских фреймворков выбрал Django. Не понимаю я, что значит эта "лёгкость". Лёгкость написания? Так в джанге она присутствует, даже более чем. Лёгкость в смысле нетребовательность к ресурсам? Так джанга и так быстро обрабатывает request и отдаёт response. Подозреваю, что "лёгкость" - это ограниченность по функционалу и отсутствие многих фич, которые идут из коробки. Вот в этом я согласен - тут джанга совсем не "лёгкая". Пишу на ней уже два года и до сих пор открываю для себя совершенно новые вещи.

в общем-то, после прочтения всяких медведов и клёвых адресов я и открыл английский вариант текста. Лучше никакого перевода, чем такой.

Разработчики джанги - велосипедисты грандиозные.

У нее нет ни одной внешней зависимости. Это и хорошо и плохо.

А что в этом плохого? Они же не переписывают заново готовые библиотеки, а просто адаптируют их как теги/фильтри/мидлвари. Это охрененно для разработки реальных проектов - залил джангу, залил проект и всё работает. С версии 1.0 она вообще сказкой кажется. Жаль не всегда получается писать именно на ней, не от меня зависит.

Нихрена они не адаптируют, они пишут свое. Девелоперы джанги кричат во всю глотку про KISS и DRY, а на деле джанга сама этим принципам следует далеко не во всем.

> Это охрененно для разработки реальных проектов - залил джангу, залил проект и всё работает.

Как вариант - установил яйцо с проектом с пом. easy_install, он стянул нужные зависимости. Все довольны, все смеются.

> С версии 1.0 она вообще сказкой кажется.

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

> Нихрена они не адаптируют, они пишут свое.

False

> Как вариант - установил яйцо с проектом с пом. easy_install, он стянул нужные зависимости. Все довольны, все смеются.

Иногда такое приходиться в проекте использовать, что яйца не катят.

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

Бред сивой кобылы. Есть у неё недостатки, это не секрет. Но по сравнению с другими фреймворками она - просто образец. Кстати, проблемы с джангой возникают в основном у людей, которые пользуются ею недолго и просто не знают, как делается правильно. Со временем начинаешь проектировать приложение таким образом, что бока не вылазят.

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

Уважаемый Румус!

А чему может научится этот (хун-)Вэбпай? У его, что есть искусственный интеллект?

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

>Уважаемый Румус!

>А чему может научится этот (хун-)Вэбпай? У его, что есть искусственный интеллект?

Хорошо они урлы только к "обработчикам", а не к "разработчикам" привязали, а то заболело бы у этих бедняг.

Следил я за этим web.py, большенство коммитов это пилёж очередного супер темплейт движка. Нафиг оно надо?:)

> print заменен на return, что привело к несовместимости с версией 0.22

Интересно, к какой версии они догадаются использовать yield?

"Нелёгкость" джанги происходит прежде всего от сильной завязанности её компонентов друг на друга. Формы и админка сильно связаны с джанговским ОРМом, многие компоненты несут с собой свои шаблоны, поэтому сторонний ОРМ и сторонний шаблонизатор в джанговском проекте использовать мало кто отваживается. Короче, пока хватает искоробочного функционала, жить с джангой легко и приятно, но как только захочется странного - всё, приехали, надо либо её патчить, либо выдумывать дикие хаки. А если ещё и админкой джанговской не пользуешься, то вообще недоумение: зачем переделывать этот комбайн на гоночный автомобиль, если можно взять готовый автомобиль. Тут и начинаешь задумываться о Werkzeug и подобных штуках.

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

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

Бугога. Это именно то закостенение мозга, о котором я говорил.

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

Я знаю не по наслышке о best practices в джанго. И я не против самого по себе их наличия. Но когда приходится сделать нечто, отличающееся от my_cool_app.views.hello_world - начинаются проблемы. И с моделями, и с формами, и с шаблонами, и с системой настроек... Решаются эти проблемы как правило зарыванием в исходники джанги, ибо документация описывает только публичный API, а не внутренний дизайн.

капча shamers какбе говорит, что разработчики джанги смущены.

http://cherrypy.org/wiki/ReturnVsYield

RTFM. yield для вывода респонза весьма неоднозначный вариант.

Никто не мешает поддерживать и yield, и return одновременно, как в CherryPy.

Тем более, что с return все начут делать так:

class hello:        
    def GET(self, name):
        response = []
        response.append(чего-то там)
        response.append(ещё чего-то)
        for line in in [тут много всего]:
            response.append(line)
        return ''.join(result)

Уж лучше yield, чем такое.

Хотя с шаблонизатором это особого значения не имеет, наверно.

Я сейчас работаю с джангой без джанговского ОРМ, сессий и админки. Суюрприз?
По поводу шаблонов - срочно умертви себя. Шаблоны в джанге одни из самых быстрых, а по удобству я им равных не видел.

А в чем проблема с таким кодом?

> Я сейчас работаю с джангой без джанговского ОРМ, сессий и админки. Суюрприз?

А чему ж ты тогда радуешься? Чем без орм, сессий и админки она хороша вообще?

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

Для тех, кто слаще морковки не пробовал... Некоторые вон орут, что виндовс хр - лучшая ОС, придуманная человечеством...

> И я ненавижу, когда меня заставляют делать так, как хотят разработчики фреймворка.

Дорогой мой начинающий разработчик! Советую ознакомиться с идеологией такого понятия как "фреймворк". Эта штука изначально подразумевает тот факт, что ты будешь под него подстраиваться, а не наоборот. Это везде так - в .NET, в Qt, в Symphony - в любом объёмном фреймворке независимо от его назначения. Теперь, когда ты ознакомился с этой великой тайной, можешь со спокойной душой лабать дальше.

> А чему ж ты тогда радуешься? Чем без орм, сессий и админки она хороша вообще?

Почему без? Я использую сторонние компоненты. Они вполне себе прилично вписались. Хотя конечно с монолитной джангой работать намного приятней.

> Для тех, кто слаще морковки не пробовал... Некоторые вон орут, что виндовс хр - лучшая ОС, придуманная человечеством...

Ну поведай же мне пример охренительных шаблонов, которые по параметрам скорость/удобство делали бы джанговские.

> ты невкурсе просто. в вебпай ты создаешь обьекты, реализующие отдельные странички. методы пост и гет должны делать ретурн тех данных, что будут отправлены в браузер. в ветке 0.2.х нужно было делать принт, и они поступали в браузер к в обычном сги

А как быть с большими или долгонакапливаемыми данными???

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

> Ну поведай же мне пример охренительных шаблонов, которые по параметрам скорость/удобство делали бы джанговские.

Блин, ну тебе не стыдно? jinja2, например.

Дурачёк ты. Гибкость мышления проявляется на этапе выбора инструмента. Хочешь MVC (MTV) - бери этот паттерн и лабай, вне зависимости от того, будет это фреймворк или набор библиотек. Ты всё равно будешь следовать этому паттерну и это не есть ограничение.

А не хочешь - тогда какого хрена ты вообще в эту сторону смотришь?

Может ты сначала результаты тестирования предоставишь, а потом будешь меня стыдить?

Сам ты дурачок.

Я тебе привожу конкретный пример - невозможность декомпозиции моделей приложения (в рамках терминологии джанго) из модуля в пакет. Это как-то обосновано идеологией MVC? Это типа DRY и KISS? Это, блин, исключительно фича языка, причем одна из наиболее базовых. Ради чего я должен сознательно от нее отказываться?

Это только первое, что на ум приходит.

> Ну поведай же мне пример охренительных шаблонов, которые по параметрам скорость/удобство делали бы джанговские.

ебанаврот, ты эту херню которая не умеет рекурсию и функции, а также крайне тормозная в пример ставишь?

> http://jinja.pocoo.org/2/documentation/faq#how-fast-is-it

The benchmarks from the testsuite show that Jinja2 has a similar performance to Mako and is between 10 and 20 times faster than Django’s template engine or Genshi.

Побольше смотри вокруг, а не только прямо вперед.

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

Насколько я знаю, jinja существенно быстрее, а ещё у них лольная реализация рекурсии - через for x in something recursive ... loop ...

> Ради чего я должен сознательно от нее отказываться?

Ради вагона джанговских удобств. Если ты этими удобствами не пользуешься - возвращайся к этапу выбора инструмента. Что тут непонятного?