Форум сайта python.su
o7412369815963
Да, кэп, это все и так прекрасно знают.
Речь как раз о том и есть, что контекст веб-запроса не должен быть глобальным стейтом. Это признак и причина плохой архитектуры.
Офлайн
Пять копеек. Зачем Веркцойг имеет свою реализацию thread local? Потому, что в stackless эти потоки не равны системным. Приходится ходить конем. А как быть в случае twisted или tornado? Повод еще раз подумать…
Офлайн
Александр Кошелев“отсутствия разделения кода”, почему это проблема? наоборот - преимущество. хочешь разделяй, хочешь не разделяй - разработчик сам проектирует приложение.
связанные с ним проблемы (например, отсутствия разделения кода на зависящий от текущего контекста (реквеста) и независящий) их мало напрягают.
Андрей Светлова что с twisted и tornado? без глобального контекста - их право, это не значит что он плох.
А как быть в случае twisted или tornado?
Офлайн
Я имею в виду, что запустить Flask под twisted не запихивая обработку запросов в threadpool - невозможно. werkzeurg.local этого не умеет, хотя для stackless отнорочек есть.
Офлайн
Андрей СветловВы, всё-таки, редкостный извращенец… Зачем такое может понадобиться, в мою плохо проснувшуюся голову не влезает.
запустить Flask под twisted
Офлайн
Хорошо. WSGI — это контейнер.
Последний год я вижу вялотекущие разговоры о том, что было бы здорово подружить WSGI с неблокирующими сокетами.
Реализовав их, например, в том же nginx - он ведь от рождения неблокирующий? Да только с thread local variables это не выйдет.
Офлайн
Андрей СветловКогда реализуют, тогда появятся соответствующие фреймворки, а пока thread local - это удобно.
Хорошо. WSGI — это контейнер.
Последний год я вижу вялотекущие разговоры о том, что было бы здорово подружить WSGI с неблокирующими сокетами.
Реализовав их, например, в том же nginx - он ведь от рождения неблокирующий? Да только с thread local variables это не выйдет.
Офлайн
Насколько я вижу, используются bottle.request и bottle.response. Что же это, как не thread local?
Офлайн
Андрей Светловв реализации requset все параметры сохраняются в том самом environ который прилетает от wsgi
Насколько я вижу, используются bottle.request и bottle.response. Что же это, как не thread local?
def __getitem__(self, key): return self.environ[key]
def __delitem__(self, key): self[key] = ""; del(self.environ[key])
def __iter__(self): return iter(self.environ)
def __len__(self): return len(self.environ)
def keys(self): return self.environ.keys()
Офлайн
Еще раз смотрю на исходники из https://github.com/defnull/bottle.git
Версия свежая, только что обновился.
bottle.Request и bottle.Response унаследованы от threading.local
bottle.request и bottle.response - экземпляры этих классов.
Что же это, как не крепкая привязка к thread local? Каким образом в одном потоке может работать несколько wsgi application одновременно?
Офлайн