At 11:35 AM 7/8/2008 -0700, Donovan Preston wrote:
On Jul 7, 2008, at 6:11 PM, Phillip J. Eby wrote:
At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
It seems to me that what is really needed here is an extension of
wsgi
that specifies how to get, set, and list request local storage, and
for people to use that instead of the threadlocal module.
I don't follow why you wouldn't just put that in the environ. (If
you need it to be carried back from the application, use mutable
objects in the environ.)
Yes, the logical place to store it is in the environ, but this whole
thread is about having an api for doing request-local storage that
doesn't involve passing the request everywhere.
Here's what I am imagining:
There's just a module, called requestlocal or something. It has an API
just like threading.local(), except the implementation can be changed
by the wsgi server.
I personally don't like the idea of having magical context, but I
think this is a practicality versus purity issue.
Yes... and the practicality of simply storing things in the environ wins. :)
Don't get me wrong: I use "magical" contexts in my libraries, both
thread-local and otherwise. Indeed, I've got one that solves the
sort of problems you guys are talking about here, at least insofar as
being able to handle Twisted or greenlets' context-swapping needs.
But for stuff you could just put in a WSGI environ, it seems like
ludicrous overkill to me.
Obviously plenty of
people have a desire to have a place to store request-local data
without passing the environment everywhere. Using threading.local is a
good way to do that, unless the server is not using one thread per
request. Giving people an interface to write to that doesn't
specifically mention threads and is customizable by the wsgi server is
what I am suggesting.
Er, and how do you propose people *access* that interface rather than
a specific implementation of it? Wouldn't we need to pass it in the
environ, thereby rendering the whole thing even more obviously moot? :)
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
