Python-сообщество

Ряд фреймворков использует сабж. Возникает вопрос - зачем нам это надо.
Варинаты ответов:
1. Это не так уж плохо.
2. Так и надо.
3. Это архитектурное решение - по другому не получается.
4. Сам не знаю, что им реквеста обычного не хватает.
5. свой ответ…

5. Это архитектурное решение потому что авторы не осилили другого.

Если речь про локальную память потоков, то:
2. Так и надо.

o7412369815963
Если речь про локальную память потоков, то:
2. Так и надо.

Вот уж не согласен. Скорее дело обстоит так, как Саня Кошелев написал.

Эээ… я (лично я) сильно сомневаюсь, чтобы например Ян Бикинг, Бен Бангерт или Армин Роначер не могли бы осилить что-либо другое, тем не менее в WebOb, Pylons и Flask thread_local таки присутствуют и активно используются. Так что на мой взгляд влияние человеческого фактора сильно преувеличено.

На мой взгляд, thread_local нужно рассматривать как очень удачный паттерн (или антипаттерн) главной целью которого является снижение связности системы применительно к многопоточным приложениям, с соответствующими накладными расходами по производительности и снижением гибкости системы. В некотором роде thread_local очень близок по идее к синглтону - тоже вроде не очень правильно, но без него ни реестр, ни абстрактную фабрику не сделаешь, ни IoC не реализуешь.

Так что ПМСМ thread_local - это обдуманное архитектурное решение по принципу меньшего зла, ну или должно таковым являться.

ziro
Эээ… я (лично я) сильно сомневаюсь, чтобы например Ян Бикинг, Бен Бангерт или Армин Роначер не могли бы осилить что-либо другое, тем не менее в WebOb, Pylons и Flask thread_local таки присутствуют и активно используются. Так что на мой взгляд влияние человеческого фактора сильно преувеличено.

А это как раз является подтверждением. Короля делает свита, поэтому авторы этих решение осознанно идут по пути упрощения. Архитектурно чистые решение имеют меньшую целевую аудиторию чем более попсовые и простые.

Для свитчера или просто мало опытного разработчика нет ничего более понятного чем глобальный контекст, в который можно гадить откуда угодно и где угодно получать данные. Это очевидно легче, чем прокидывать контекст явным образом в отдельные компоненты системы. То что глобальный контекст является анти-паттерном по науке их мало смущает – пипл хавает, а связанные с ним проблемы (например, отсутствия разделения кода на зависящий от текущего контекста (реквеста) и независящий) их мало напрягают.

Поэтому да, не осилили сделать понятно и просто без него и не хотели, а главное не осилят потребители.

ziro, пусть WebOb и Flask останутся на вашей совести.
Использование threadlocal в Pylons - ошибка.
В Pyramid thread locals крайне ограничены - только для конфигурации.


Александр Кошелев, осилили они все прекрасно - достаточно в исходники сначала глянуть.

Андрей Светлов
ziro, пусть WebOb и Flask останутся на вашей совести.

Конечно, пусть останутся. Тем более, что использование thread_local является официальной рекомендацией WebOb
http://pythonpaste.org/webob/do-it-yourself.html#url-generation-and-request-access
а во Flask вся работа с окружением идет через модуль https://github.com/mitsuhiko/flask/blob/master/flask/globals.py в котором активно используется LocalStack и LocalProxy отсуда - https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/local.py

Ну а то, что во werkzeug используется собственная реализация thread_local не делает их менее thread_local, чем threading.local

Андрей Светлов
Использование threadlocal в Pylons - ошибка.

Нет. Это самое разумное решение, которое можно использовать в модели выполнения Pylons, когда класс контроллера импортируется на лету.

WebOb: пример в документации - есть. Использования thread locals в коде - нет.
Werkzeurg: модуль для thread locals - есть. Он не используется ядром самой библиотеки, только примерами.
Flask: был неправ. Извиняюсь.
Pylons: лет пять назад request передавался явно первым параметром в методы контроллера. Импортировать на лету это не мешало. Потом настал черный день
и автор решил, что неявная запись будет чуть короче.

Все еще считаю, что thread locals не должны выходить за пределы global state - настроек конфигурации. Передавать в них объекты вроде request - не следует.

Андрей Светлов
Все еще считаю, что thread locals не должны выходить за пределы global state - настроек конфигурации. Передавать в них объекты вроде request - не следует.

request в локальной памяти - то что доктор прописал…

клиент конектится - создается поток, все данные которые касаются только данного клиента (get, post данные, данные подгруженные из БД) разумно держать именно в этом потоке.
клиент отключился - уничтожаем все данные локального потока, они больше никому не нужны, не зачем транжирить память.

request может не быть в thread.locals, но все равно он в локальной памяти потока…

Отредактировано (Март 31, 2011 14:24:57)