Pull to refresh

Comments 44

Очень вовремя, очень качественно, отличная тема. Предлагаю не останавливаться на достигнутом :)
Спасибо :) Вопрос только о чём ещё будет интересно узнать..

И ещё. Я когда потом сам всё это читал, испытывал не лучшые ощущения – как-то очень тяжело. Может кто подскажет, в чём дело и как можно улучшить стиль?
Для начала спасибо.
Хотелось бы увидеть установку и настройку в первую очередь под апач этого дела. Ну либо под что то другое под что принятно или что чаще используется.
Пробовал пускать на WSGI сервере CrerryPy, wsgiref и что то ещё приложение типа "Hello world". Ab дает результаты сравнимые с PHP+Apache. Но я не думаю что сервер должен так работать в продакшне.
А у вас Python бежал в mod_python или CGI? Вообще по-моему если фреймворк даёт результаты, сравнимые с пустым PHP-скриптом, то это неплохо.

А по поводу настройки.. Я мог бы отписать, как я это делал под mod_python на FreeBSD и Windows, но наверно попозже :)
Во-первых мне удобнее когда со мной на ты :)
Пробовал и под апачем mod_python но без wsgi.
Пробовал как в приведенном примере

if __name__ == '__main__':
   from paste import httpserver
   httpserver.serve(app, host='127.0.0.1', port='8080')

только CherryPy и wsgiref.
Я попросил эту тему потому что только вот заинтересовался питоном и изучаю технологии. Поэтому возможно что то не так делаю как делают прошареные в этой теме люди. Мне кажется что это должно крутиться как то на апаче. + в приведенном примере не очень удобно что при каждом изменении скрипта нужно его прерывать и заново запускать... изменения почему то до этого не вступают в силу. Повторюсь, возможно я что то не так делаю.
Изменения не вступают в силу – так ведёт себя любой скриптовый язык. Вот если разбить скрипт на файлы и перегружать изменяющиеся части – получится как раз то, что есть во фреймворках, то есть HTTP-сервер для тестирования. (А в mod_python вообще нужно перегружать сервер, чтобы изменения вступили в силу.)

С CherryPy не работал, ничего толком не подскажу. И не возьмусь даже советовать, на какую технологию больше обратить внимание, потому что это, пожалуй, ответственный выбор. Могу только заметить, что Python – один из самых шустрых скриптовых языков с большой перспективой, и наверняка ни одна из дорог не будет тупиковой
Хотелось бы увидеть установку и настройку в первую очередь под апач этого дела. Ну либо под что то другое под что принятно или что чаще используется.

AFAIK, наиболее популярно Apache+mod_python и lighttpd/nginx+FastCGI.

Я в свое время писал о способах развертывания WSGI-приложений (не важно, используется Pylons или Django, поскольку оба поддерживают WSGI).
Интересная вводная. Впрочем, не оставляет ощущение того, что это все - копирование того, что уже есть и давно работает.
Так никто и не утверждает, что это что-то революционное.

WSGI - это "продолжение" CGI. Pylons многие компоненты заимствовал. WebHelpers, Routes - прямые порты с рельсов. Myghty (из которого "вырос" Mako) - порт HTML::Mason. Разве что Paste несколько оригинален. Разработчики просто взяли то, что считали удачным. Если этого не было на Python — писали/портировали, но не один-в-один, а с учетом Python-специфики.

Именно поэтому вас и не покидает ощущения, что где-то уже это видели. Просто теперь это стало более "питоничным".
Попытка внести какой-то порядок в "современное многообразие языков программирования и фреймворков"... На самом деле очередной интерфейс, который никак не повлияет на удобство переноса проекта с сервера на сервер, по крайней мере до тех пор пока не станет единогласныс стандартом. Думаю не станет.
....имхо конечно
Это уже стандарт питона, и все крупные фреймворки его поддерживают, и все крупные сервера его поддерживают. А Pylons, имхо, стремительно развивается. Почва для продуктивного развития вроде бы есть :)
я бы пока не стал на столь молодых ставить проекты
…наряду со специфичными для WSGI (environ['wsgi.input'] содержит поток для чтения данных, переданных POST-методом).

То есть изобрели велосипед — стандартный POST-поток 20-ти неполных лет от роду заставляют воспринимать как что-то новое. В формах как прикажете писать, «method = "wsgi"»? Словоблудие это всё, простите меня.
Тут абсолютно ничего нового нету :) Я всего лишь хотел подчеркнуть, что в одном словаре environ содержится вся информация о запросе, часть которой имеет вид CGI-окружения, а часть – более специфичные названия.
То-то и оно, что названия. Вспомните дзен Питона - «Явное лучше подразумеваемого» ( «Explicit is better than implicit»), «Особые случаи не такие уж особые, чтобы нарушать правила» («Special cases aren't special enough to break the rules»), ну и тэ дэ. Тянет на холивор :)
Стандартный пост поток никуда не делся он и тут остался стандартным просто содержится не в переменной названой POST либо как то ещё, ну и может немного другие методы работы отличные от $_POST['var'].
См. мой коммент чуть повыше вашего. Зачем, скажите, называть POST как-то иначе, если он остался всё тем же. Даже верстальщик напишет в форме «method="post"». А кодера зачем-то приучают к environ['wsgi.input']. Зачем - понятно, чтобы название технологии было всегда перед глазами, чтобы простой кодер за эту им же себе разрекламированную марку устраивал кругом холиворы (как я сейчас, только наоборот) и рекламировал ее другим непосвященным, кодерам и некодерам. Чтобы если начальник случаем заглянет через плечо и спросит «а это вот что такое за взги?», а кодер, рдея от осознания своей гениальности, объяснит, что это сверхсовременная платформа такая... Но это бессмысленно. Проще надо, проще!
Можно вопрос? На чём Вы програмите?
Если уж не нравится что то отличное от POST то никто Вам не запрещает назвать это хоть своим именем, если так нравится. В форме пост и остается постом. Если уж тут пугают другие буквы, то это уже сугубо личные проблемы.
Что касается разрекламированной новой технологии, то Вы то и можете сидеть в прошлом веке, можете програмить на бейсике, можете использовать не менее разрекламированный RoR, .NET либо ещё что нибудь, можете делать что хотите, а в соседнем топике трубить что технологии не развиваются... Но это бессмысленно. Проще надо, проще!
Не обижайтесь, пожалуйста. Я вообще то работаю веб-технологом и ни на чем по долгу службы не программирую. Я знаю PHP, Perl, Parser и Python и перед последним глубоко преклоняюсь. POST своим именем называть я не желаю по вышеозначенным причинам. Технологии развиваются, я не спорю.

Вы людей когда-нибудь нанимали на работу? Погружали их в готовый код с требованиями разобраться? Угадайте, сколько свежепришедших кодеров будут смотреть на wsgi, как баран на новые ворота? Я понимаю, есть гениальные люди, разбирающиеся во всем за пять минут, но есть лузеры, на которых сваливают рутину. Багов больше из-за последних. Python создавался с идеей удобочитаемости, осваиваемости кода, которой во всем этом я пока не наблюдаю, вот и вся причина для моего ворчания.
Я кажется начинаю вас понимать :) Я тоже уважаю Python и ценю удобочитаемость в нём. Но с Pylons-ом, под который и пишется настоящий код, всё в порядке:
user_name = request.params.get('user_name', None)
request.params содержит данные из GET и POST.
Я совсем не обижаюсь :) или по моему комменту кажется что я обиделся? Я никогда не обижаюсь.
Видимо это сделано из расчета на то что в 'wsgi.input' может быть тело PUT, а не только POST.
UFO just landed and posted this here
Кармаграфсмешно ничего серьёзного конечно, но всё же.
Вот выжимка из моего имхо:
— в Pylons замечательные шаблоны, с чистым питоном, а не чёрти что
— в Pylons я использую SLQAlchemy, а не чёрти что
— в Pylons у меня есть контроллёры, а в Django не то View, не то ещё что-то
— код в Pylons получается более компактным и понятным
— ну и просто на подсознательном уровне больше понравился Pylons, полноценно базирующийся на Paste и WSGI
Хотя всё это может со временм измениться вплоть до противоположного..

У вас вероятно противоположное мнение?
Обязательно попробую Pylons, но сейчас пишу на Django - чрезвычайно удобно.
  • То что шаблонах django нет чистого питона вовсе не так уж и плохо, код будет явно чище - кроме логики отображения в них никто ничего засунуть не сможет;

  • View в Django - это и есть контроллеры в традиционном понимании этого термина, Templates же - это представление, просто они немного сместили терминологию, что поначалу немного непривычно. Где-то на их сайте написано, почему они так поступили.
  • Да-да, с объективной и научной стороны всё так и есть :) Я высказывался чисто субъективно, делился впечатлениями)
    UFO just landed and posted this here
    Спасибо за столь обширный комментарий :) Надо сказать, я никого из Pylons, Django не защищаю на самом деле, я скорее за справедливую здоровую конкуренцию. Поэтому последняю мысль очень поддерживаю (про гибкость и связность).
    UFO just landed and posted this here
    Врядли это есть на Хабре.. А в RSS отдавать посты об изменении кармы? Надо будет подумать :)
    UFO just landed and posted this here
    Хорошая идея.
    Очень интересно, спасибо!
    Продолжайте в этом же духе. Будет еще интересно почитать про Ваш опыт использования django.
    Спасибо :)
    Правда, мой скромный опыт использования Django говорит, что в следующий раз я скорее всего буду использовать Pylons .) Хотя конечно Django очень достойная вещь.
    Примерно с этой мыслью в голове и писал (: Надеюсь, дальше будет только лучше (конечно не обязательно в моём исполнении), и будет больше баллов и участников в обсуждении.
    Кто бы мне кармы добавил... было б и в моем исполнении.
    Хотелось бы еще увидеть реальных хостинг-провайдеров, которые предоставляют хостинг с Python за разумные деньги.
    Только не сочтите за рекламу.
    В Украине есть как минимум один - tophost.com.ua, я им пользуюсь.
    Отличная штука. Запомню.
    UFO just landed and posted this here
    к сожалению о самом Протоколе взаимодействия ни слова…
    а очень жаль,
    меня интересовало именно как именно обменивается WEB сервер и WEB Приложение
    Sign up to leave a comment.

    Articles