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 : [EMAIL PROTECTED] : http://blog.ianbicking.org
_______________________________________________
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
