Sooner or later you have some things you want to have in every single view or helper function or whatever. In PHP the way to go are global variables. However that is not possible in WSGI applications without a major drawback: As soon as you operate on the global namespace your application is not thread safe any longer.
The python standard library comes with a utility called “thread locals”. A thread local is a global object where you can put stuff in and get back later in a thread safe way. That means whenever you set or get an object to / from a thread local object the thread local object checks in which thread you are and delivers the correct value.
This however has a few disadvantages. For example besides threads there are other ways to handle concurrency in Python. A very popular approach are greenlets. Also, whether every request gets its own thread is not guaranteed in WSGI. It could be that a request is reusing a thread from before and data is left in the thread local object.
Here a simple example how you can use werkzeug.local:
from werkzeug import Local, LocalManager
local = Local()
local_manager = LocalManager([local])
def application(environ, start_response):
local.request = request = Request(environ)
...
application = local_manager.make_middleware(application)
Now what this code does is binding request to local.request. Every other piece of code executed after this assignment in the same context can safely access local.request and will get the same request object. The make_middleware method on the local manager ensures that everything is cleaned up after the request.
The same context means the same greenlet (if you’re using greenlets) in the same thread and same process.
If a request object is not yet set on the local object and you try to access it you will get an AttributeError. You can use getattr to avoid that:
def get_request():
return getattr(local, 'request', None)
This will try to get the request or return None if the request is not (yet?) available.
Note that local objects cannot manage themselves, for that you need a local manager. You can pass a local manager multiple locals or add additionals later by appending them to manager.locals and everytime the manager cleans up it will clean up all the data left in the locals for this context.
Releases the contents of the local for the current context. This makes it possible to use locals without a manager.
Example:
>>> loc = Local()
>>> loc.foo = 42
>>> release_local(loc)
>>> hasattr(loc, 'foo')
False
With this function one can release Local objects as well as StackLocal objects. However it is not possible to release data held by proxies that way, one always has to retain a reference to the underlying local object in order to be able to release it.
New in version 0.6.1.
Local objects cannot manage themselves. For that you need a local manager. You can pass a local manager multiple locals or add them later by appending them to manager.locals. Everytime the manager cleans up it, will clean up all the data left in the locals for this context.
Changed in version 0.6.1: Instead of a manager the release_local() function can be used as well.
Like make_middleware but for decorating functions.
Example usage:
@manager.middleware
def application(environ, start_response):
...
The difference to make_middleware is that the function passed will have all the arguments copied from the inner application (name, docstring, module).
This class works similar to a Local but keeps a stack of objects instead. This is best explained with an example:
>>> ls = LocalStack()
>>> ls.push(42)
>>> ls.top
42
>>> ls.push(23)
>>> ls.top
23
>>> ls.pop()
23
>>> ls.top
42
They can be force released by using a LocalManager or with the release_local() function but the correct way is to pop the item from the stack after using. When the stack is empty it will no longer be bound to the current context (and as such released).
By calling the stack without arguments it returns a proxy that resolves to the topmost item on the stack.
New in version 0.6.1.
Acts as a proxy for a werkzeug local. Forwards all operations to a proxied object. The only operations not supported for forwarding are right handed operands and any kind of assignment.
Example usage:
from werkzeug import Local
l = Local()
# these are proxies
request = l('request')
user = l('user')
from werkzeug import LocalStack
_response_local = LocalStack()
# this is a proxy
response = _response_local()
Whenever something is bound to l.user / l.request the proxy objects will forward all operations. If no object is bound a RuntimeError will be raised.
To create proxies to Local or LocalStack objects, call the object as shown above. If you want to have a proxy to an object looked up by a function, you can (as of Werkzeug 0.6.1) pass a function to the LocalProxy constructor:
session = LocalProxy(lambda: get_current_request().session)
Changed in version 0.6.1: The class can be instanciated with a callable as well now.
Keep in mind that repr() is also forwarded, so if you want to find out if you are dealing with a proxy you can do an isinstance() check:
>>> from werkzeug import LocalProxy
>>> isinstance(request, LocalProxy)
True
You can also create proxy objects by hand:
from werkzeug import Local, LocalProxy
local = Local()
request = LocalProxy(local, 'request')