Зачем?

А зачем?

Вы не освоили принципы ООП?

flask, bottle, baito.

Вы не освоили принципы ООП?

Чтобы обработать сраный реквест ООП не нужен.

Чтобы обработать сраный реквест ООП не нужен.

А какая разница? Обработан ли request функцией или объектом класса , и в первом и во втором случае это всеравно объект. И потом Вы всеравно не уходите от ООП. Кажется вы используете webob? А тот в свою очередь cgi.FieldStorage. Вас не устраивает? Ну напишите парсинг request используя только функции и глобальные переменные

Они там почти все такие. А надо ли? Так хочется наляпать спагети код?

Чтобы обработать сраный реквест ООП не нужен.

Как же не нужен? Нужны объекты которые представляют запрос, поля формы, ответ. А наляпать можно и CGI скрипт.

И потом Вы всеравно не уходите от ООП

Я вас умоляю, какой там ООП? Так, структуры с методами, токмо ради группировки логики.

Как же не нужен? Нужны объекты которые представляют запрос, поля формы, ответ. А наляпать можно и CGI скрипт.

Они путают python с C++. Разницы методов класса и функций никакая , в первом случае это всего лишь удобная форма упаковки порождающая новое пространство имен. В python объектом является все.

Как же не нужен?

ООП не начинается с заветного слова class и тем более им не заканчивается.

Я вас умоляю, какой там ООП? Так, структуры с методами, токмо ради группировки логики.

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

и в первом и во втором случае это всеравно объект.

Как мило, если функция объект, то значит у нас ООП.

Всё конечно верно, ООП не нужен. Но проблемы в том, что во flask, bottle, baito ООП уже есть.

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

Да, но при чем тут ООП?

Но проблемы в том, что во flask, bottle, baito ООП уже есть.

Под капотом. Наружу это не сильно стремится.

Да, но при чем тут ООП?

Давай спорить не будем , ты кажется что-то там писал типа оболочки над webob? Я смотрела давеча на гитхабе. Давай сделаешь так, напиши парсинг request запросов используя только функции. Не используй cgi сам напиши парсинг. Раз уж начал писать свой фреймворк. А потом покажешь.

Раз уж начал писать свой фреймворк.

Нет, это примитивный клей. NIH'ом страдаю не сильно.

Пойнт был в том что, для обработки запроса в приложении (не во *фреймворке*) ООП не нужен.

парсинг request запросов используя только функции

Охренеть какая сложность.

В нашем случае класс просто порождает пространство имен, все так. Но какое отношение имеет пространство имен к ООП? Зачем мне новое пространство имен, если я все равно больше одного класса в модуле не пишу? Ладно в яве мне приходится код размещать в основном в stateless классах (просто яйцеголовые теоретики без практики, которые делали яву, не знали, что прикладной код на 90% состоит из процедур, и только на 10% из объектов, но поддавшись моде «ООП наше фсио», поддержку функций и нормальных модулей не сделали), но в питоне же языковая поддержка модулей, это же просто мега фича!

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

Но... зачем!?

Pylons

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

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

Из популярных cherrypy, webpy, TG. В общем, ушибленных жабкой хватает.

принудительное ООП

Pylons

Так вы о контроллерах в виде класса?

Так автор Pylons понял что это не хорошо(по крайней мере в питоне), и начал пилить Pylons2, но потом увидел repoze.bfg, и отказался от этой идеи в пользу объединения усилий.

Turbogears2 надстройка над Pylons1 так что RIP

В webpy методы проецируются на HTTP действия так что вообщем-то получается симпотично