Веб-шлюз взаимодействует через интерфейс в Python 3
Я наконец пришел к заключению, что больше не могу позволять себе просто надеяться, что продолжающийся Py3k/WSGI disasterissues будет разрешен в ближайшее время, таким образом, я должен буду подготовиться идти дальше.
К сожалению, мои доступные варианты не кажутся намного лучше:
- В то время как я нахожу несколько различных модулей Python для FastCGI рассеянными вокруг сети, ни один из них, кажется, не привлекает очень (если таковые имеются) внимание и/или обслуживание, особенно относительно Python 3.x, и трудно различать, который, если таковые имеются, действительно жизнеспособны.
- Падение полностью назад на встроенный модуль CGI едва лучше, чем создание чего-то самостоятельно с нуля (хуже, существует важная ошибка или два там, который не может привлечь внимание до Python 3.3).
- Нет никакого более высокого греха, чем обработка HTTP непосредственно в производственном веб-приложении. И так или иначе, это все еще изобретает велосипед.
Конечно, кто-то там развертывает веб-приложения на 3.x в производстве. Какой интерфейс шлюза Вы используете, с который модуль/библиотеки, и почему?
2 ответа
Кандидаты на выпуск CherryPy 3.2 поддерживают Python 3.X. Поскольку он поддерживает WSGI только на уровне интерфейса веб-сервера, а не во всем стеке, вы изолированы от проблем, связанных с изменением WSGI. CherryPy имеет собственный внутренний сервер WSGI, но также может работать под Apache / mod_wsgi с Python 3.1+. См .:
http://www.cherrypy.org/wiki/WhatsNewIn32 http://code.google.com/p/modwsgi/wiki/SupportForPython3X
bottle поддерживает Python 3, но страдает из-за сломанной stdlib. Однако multipart повторно реализует cgi.FieldStorage и может использоваться с бутылкой для создания веб-приложения Python 3 WSGI. Я только что опубликовал демо. На данный момент это просто тест, но, насколько я могу судить, он работает хорошо.