current_app และออบเจ็กต์ g

current_app is a proxy that always points to the app handling the work right now. Import it whenever you need the active application.

Importing your app object directly causes circular imports as projects grow. current_app sidesteps that by resolving the app at runtime.

A common use is reading settings: current_app.config gives you the active app's configuration without importing the app module.

current_app only works while an app context is active. Inside a view that is automatic, since the request pushed one for you.

g is a simple scratchpad for one request. Attach anything to it and read it back later in the same request.

The g object is reset for every request. Data you stash on it never leaks into another visitor's request.

Use g to share work across functions in one request, like caching the current user so you fetch it from the database only once.

Do not treat g as a database. It forgets everything the moment the request ends, so use it only for that request's lifetime.

Surprisingly, g belongs to the app context, not the request context. In practice both exist during a request, so it just works.

Pair g with teardown handlers to close what you opened, like closing a database connection after the response is sent.

They pair nicely: read settings from current_app, then stash request-specific results on g so the rest of the request can reuse them.

Let us pin down what g is for.

Two handy proxies: current_app finds the active app and its config, while g is a per-request scratchpad you wipe clean each time. 🎉