





Это просто: вы создаете приложение WSGI как обычно, а затем оборачиваете это приложение в промежуточное программное обеспечение WSGI перед его запуском.
См. этот код из Bloog, чтобы узнать, как firepython добавляется в качестве промежуточного программного обеспечения.
Этот является - общий способ добавления промежуточного программного обеспечения WSGI. Что касается идеи Django о «промежуточном программном обеспечении», вам нужно будет обратиться к руководству по Django для этого.
Фреймворк веб-приложений GAE не сопоставляется однозначно с фреймворком Django. Было бы сложно сделать то, что вы хотите, без самостоятельной реализации какого-либо адаптера, я не знаю каких-либо адаптеров сторонних обработчиков для этого.
Тем не менее, я обычно использую app-engine-patch, поэтому я могу использовать последнюю версию 1.0.2 Django с AppEngine, а затем вы можете просто включить промежуточное ПО Django обычным способом с файлом setup.py. Если вам нужно, вы, вероятно, можете просмотреть адаптер app-engine-patch, чтобы увидеть, как они это делают, и начать с этого в качестве фреймворка.
«Промежуточное ПО» в понимании Django - это своего рода процессор запросов / ответов, весьма отличный от того, что WSGI называет «промежуточным ПО». Подумайте: подобное django промежуточное ПО добавит атрибут session к объекту запроса на основе того, что Beaker (промежуточное ПО WSGI) поместил в environ['beaker.session']. Хотя добавление промежуточного программного обеспечения WSGI в стек должно быть простым (вы уже работаете на уровне WSGI в своем main.py), добавление процессора запросов / ответов зависит от того, как запрос и ответ абстрагируются от WSGI.
Как это можно сделать с помощью Werkzeug (который является базовым набором инструментов WSGI), описано в Werkzeug вики и в одном из его модули contrib.
Это хорошее начало, но я ищу более общий способ добавить любое промежуточное программное обеспечение django. Я посмотрю, как работает Fire Python WSGI.