[Web-SIG] Alternative to threading.local, based on the stack
dsposx at mac.com
Tue Jul 8 20:35:36 CEST 2008
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
>> 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. 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.
More information about the Web-SIG