It is often needed that ‘middleware’, ‘responders’, ‘helpers’ and perhaps ‘utilities’ have access to objects within the context of the running application. To provide this context there is the big ‘g’ global.
The global allows us to provide convenient errors when working outside of the context of application or request where a responder is not being used.
All requests are placed in threads, even as per WSGI. Hence the request can only be accessed from a utility function for example when a request is being processed.
There are builtin globals such a ‘current_request’, ‘app’ and ‘router’.
All middleware and responders
__init__ is within the global context of the python namespace. Hence what you do here happens before a request is even made. You can use the constructors to establish database connection for example. Then reference it in ‘g’.
Once a thread is processing a request it has access to globals via ‘g’ and utilities, helpers can access request data from
g.current_request is builtin which only references the request object for the specific thread.
Request objects simply provides a representation of the client request. Such as route, method and payload. Different handlers such as wsgi extend the request methods and properties.
The following raises an error
from luxon import g print(g.app.path) # Will Raise NoContextError.
The following works as expected
from luxon import g from luxon.core.handlers.wsgi import Wsgi app = Wsgi(__name__) # G App is equal to app. print(g.app.path) # Works
You can create global objects on each process and reference them in ‘g’.
from luxon import g db = connect_to_db() g.db = db
from luxon import g # However this must be done within the context. print(g.current_request.method)