Как использовать Python для веб-разработки, не полагаясь на фреймворк?

Question

Я знаю, что различные фреймворки имеют свои преимущества, но я лично хочу, чтобы моя веб-разработка на python была максимально простой: меньше писать в фреймворк, больше писать python .

Единственное, что я нашел до сих пор, что позволяет мне сделать это наиболее очевидным из возможных способов, это web.py , но у меня есть небольшие опасения по поводу его производительности.

Для тех из вас, кто использует nginx (или другой вариант) + mod_wsgi + web.py ... как производительность? Можно ли его еще улучшить?

Для тех из вас, кто использовал web.py, понравилась эта идея и она продолжила писать что-то лучше или нашла что-то лучше ... не хотите указать мне источник?

Я хотел бы услышать обо всех заметных, минимальных, но мощных подходах.

Answer 1

Путь - это wsgi .

WSGI - это интерфейс шлюза веб-сервера . Это спецификация для веб-серверов и серверов приложений для взаимодействия с веб-приложениями (хотя она также может использоваться для более чем). Это стандарт Python, подробно описанный в PEP 333 .

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

Вот привет мир, написанный непосредственно для wsgi:

def application(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

Поместите это в file.py, укажите на него конфигурацию mod_wsgi apache, и он запустится Чистый питон. Нет импорта. Просто функция Python.

Если вы действительно пишете свой собственный каркас, вы можете проверить werkzeug . Это не инфраструктура, а простая коллекция различных утилит для приложений WSGI, ставшая одним из самых передовых модулей утилит WSGI. Он включает в себя мощный отладчик, полнофункциональные объекты запросов и ответов, утилиты HTTP для обработки тегов сущностей, заголовки управления кэшем, даты HTTP, обработку файлов cookie, загрузку файлов, мощную систему маршрутизации URL-адресов и несколько дополнительных модулей для сообщества. Снимает скучную часть с рук.

Answer 2

Забавно, что, даже когда мне задают вопрос о том, как писать без фреймворка, каждый все равно пытается продвигать свои любимые фреймворки. ОП жалуется на то, что не хочет «тяжеловесных фреймворков», а в ответах упоминается Искривленный всех вещей ?! Давай сейчас, действительно.

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

Чтобы пойти по этому пути, вы, как правило, захотите ознакомиться с основами HTTP и CGI (поскольку WSGI очень сильно наследует эту более раннюю спецификацию). Это не обязательно подход, рекомендуемый начинающим, но вполне выполнимый.

Я хотел бы услышать обо всех заметных, минимальных, но мощных подходах

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

Answer 3

Вы также можете проверить cherrypy . В центре внимания cherrypy находится фреймворк, позволяющий писать на python. Cherrypy имеет свой собственный довольно хороший веб-сервер, но он совместим с wsgi, поэтому вы можете запускать приложения cherrypy в apache через mod_wsgi. Вот привет мир в вишневом:

import cherrypy

class HelloWorld(object):
    def index(self):
        return "Hello World!"
    index.exposed = True

cherrypy.quickstart(HelloWorld())

Answer 4

+ 1 ко всем ответам с WSGI.

В последнее время Эрик Флоренсо написал отличное сообщение в блоге, которое вы должны прочитать: Писать молниеносно, бесконечно масштабируемые, чистые утилиты WSGI . Это даст вам лучшее представление о чистом WSGI за пределами Hello World. Также обратите внимание на комментарии, особенно на первый комментарий Кевина Дангура, в котором он рекомендует по крайней мере добавить WebOb в ваш набор инструментов.

Answer 5

Что бы это ни стоило, я написал свой сайт на mod_python без какой-либо промежуточной структуры, такой как Django. У меня действительно не было причин жаловаться. (Ну, может быть, немного, mod_python несколько необычен, но не в общих случаях использования). Одно можно сказать наверняка, это точно позволит вам написать Python; -)

Answer 6

Почему вас беспокоит производительность web.py? Как я упоминал здесь , мы используем CherryPy (веб-сервер, «встроенный в» web.py) позади nginx для обслуживания большей части HTML на Oyster.com - nginx распределяет трафик между 2 или 3 веб-серверами, на каждом из которых запущено 4 процесса Python, и мы можем легко обрабатывать сотни запросов в секунду.

Oyster.com - это крупномасштабный веб-сайт, насчитывающий в среднем 200 000 динамически генерируемых просмотров страниц в день и достигающий гораздо более высоких показателей, чем этот. Однако мы используем сеть доставки контента (CDN) для наших статических ресурсов, таких как изображения и CSS.

Мы определенно заботимся о производительности (большинство наших страниц отображаются менее чем за 25 мс), но web.py не является узким местом. Нашими узкими местами являются шаблонный рендеринг (мы используем Cheetah , который достаточно быстрый, но не слишком быстрый) и запросы к базе данных (мы интенсивно кешируем и сохраняем количество запросов к базе данных на страницу на 0 или 1) и доступ наши сторонние поставщики цен на отели (доступ к ним осуществляется при выполнении поиска с датами, которые мы еще не кэшировали).

Помните, преждевременная оптимизация - корень всего зла - если вы не используете google.com, web.py, вероятно, будет работать для вас.

Answer 7

Я думаю, что это зависит от определения того, что такое фреймворк и что он должен делать для вас.

Как указывалось, очень минимальной "структурой" будет WSGI, поскольку он определяет только один небольшой интерфейс для взаимодействия с веб-сервером. Но это мощный подход из-за промежуточного программного обеспечения, которое вы можете установить между вашим приложением и сервером.

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

Если вы пойдете дальше, вы можете прийти к Pylons, Turbogears или Django, после этого, возможно, Zope, но он станет больше, и, возможно, боль, а также вы всегда принимаете во внимание мнение этой структуры.

В последнее время я все больше и больше пользуюсь (из Zope / Plone) repoze.bfg . Он очень маленький, не поставляется в комплекте с ORM (поэтому вы можете использовать SQLAlchemy, Storm или просто перейти к объектной базе данных, например ZODB ). То, что он делает, в основном обрабатывает переход от URL к представлению, которое является функцией. Он поддерживает как URL-сопоставление (как маршрут), так и обход объектов, что в некоторых случаях, IMHO, очень полезно. если у вас не очень строгое отображение. Хорошо, что он напрямую поставляется с инфраструктурой безопасности на основе ACL, которую можно использовать, если вы хотите, чтобы IMHO был очень практичным. Таким образом, вам не нужны декораторы, которые, кажется, используются в основном для таких вещей.

И, конечно, он основан на WSGI. Также ищите repoze subversion repository для довольно большого количества промежуточного программного обеспечения, а материал Paste также очень полезен для задач, связанных с WSGI.

Answer 8

Я написал несколько небольших веб-приложений, использующих mod-python и PSP - эквивалент mod-python для php.

В одном случае я написал веб-страницу, которая генерирует примечания к выпуску путем проверки нашего репозитория исходного кода. Я переписал его на PHP и с удивлением обнаружил, что версия PSP была примерно на 20% быстрее, а также примерно вдвое меньше строк кода.

Так что, по крайней мере, для небольших проблем, psp работал хорошо для меня.

Answer 9

Мне очень нравится Google AppEngine. Я использую ORM и систему шаблонов, но в остальном следую REST-шаблонному дизайну и просто реализую методы Python для соответствующих HTTP. Это делает необработанное HTTP-взаимодействие центральным и, необязательно, дает вам другие возможности для использования. Кроме того, вам больше не нужно настраивать и управлять своей средой развертывания!

Answer 10

Что не так с Джанго? Это не заставляет вас использовать его ORM, а контроллеры - это просто обычные функции Python вместо Rails-подобных методов классов. Кроме того, маршрутизация URL-адресов выполняется с помощью регулярных выражений, а не с помощью другого синтаксиса, разработанного каркасом. Если вам все равно кажется, что django слишком велик, я рекомендую взглянуть на Werkzeug