[Web-SIG] Alternative to threading.local, based on the stack

[Donovan Preston]

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. 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.

Donovan