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

[Phillip J. Eby]

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?  :)