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

[Ian Bicking]

Phillip J. Eby wrote:
>>  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?  :)

I can't decide what the question is here.  You mean, how can a greenlet 
request-local provider indicate that they are providing a way of getting 
the current request?  Or, how can a consumer get access, given that it 
can live in any module, and the consumer presumably doesn't have an environ?

I imagine from what Donovan says that there would actually be one 
module, requestlocal, and one implementation, and that implementation 
would be awesome and support greenlets and threads, and whatever else 
comes along (which luckily is not much else), and I guess maybe has a 
middleware that would register the request on entry and deregister it on 
exit, and consumers would do:

   import requestlocal

   def whatever():
       environ = requestlocal.get_request()

and we'd just all agree on this singular implementation, because I don't 
see any way around that.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org