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