> application and request context, context locals, local proxies
Those are just different names for the same thing. Maybe the docs are a bit too in-your-face with the contexts but I rather expose people to it early to avoid issues down the line.
Django for instance does not have equivalents for application and request contexts and the end result is that people often write thread unsafe code and you can only have one application per Python interpreter. Flask does not have those restrictions. You can have as many Flask applications living side by side. And that is possible because of the contexts.
There is a difference. Having a request or application context that encapsulates state is one thing, an architectural decision that simplifies multi-tenancy and makes many uses of Flask more performant. These are "simple", in that they are an obvious and easily-explained solution to a technical problem that exists by necessity.
Global proxies to local state are another beast entirely. They are "easy" in that they remove the need to pass application and request objects through every called function, but they are not "simple" -- they rely on intimate details and peculiarities of Python's module and import system, and its capacity for thread-local state, not to mention Python's robust context unwinding features in the case of exceptions. Overuse of context-proxies leads to the same software engineering challenges as overuse of globals, in that it becomes difficult to reason about the calling semantics of functions which rely on context state being present, or mutate context state through proxies. For example, in order to test a view function, you will at a minimum need to set up an application context, but also need to set up any custom context your app relies on. It's not always obvious how to do this, leading to documentation [1] that I notice has already been confusing people on the mailing list.
So I wouldn't conflate the two mechanisms. Application- and request-local context is a pre-requisite for multi-tenant applications and a conceptual simplification. Module-level proxies are a cute trick that makes programmers' lives easier, but undoubtedly creates more convoluted semantics and internal operation.
I learned that you need context locals in web applications or beginners will write themselves into a corner where they have an architectural problem on their hand they can't fix later on.
Yes, it's not the best solution, but passing things around isn't either.
Those are just different names for the same thing. Maybe the docs are a bit too in-your-face with the contexts but I rather expose people to it early to avoid issues down the line.
Django for instance does not have equivalents for application and request contexts and the end result is that people often write thread unsafe code and you can only have one application per Python interpreter. Flask does not have those restrictions. You can have as many Flask applications living side by side. And that is possible because of the contexts.