I was talking today to a colleague of mine about Python web frameworks and our impressions about them. I told him I think Flask having a global request smells badly and is an anti-pattern.
The docs say about request context:
In contrast, during request handling, a couple of other rules exist:
- while a request is active, the context local objects (flask.request and others) point to the current request.
- any code can get hold of these objects at any time.
I think I understand the idea behind this design decision -- to make the application simpler. It's just a compromise, like in the case of Thread Locals:
Yes it is usually not such a bright idea to use thread locals. They cause troubles for servers that are not based on the concept of threads and make large applications harder to maintain. However Flask is just not designed for large applications or asynchronous servers. Flask wants to make it quick and easy to write a traditional web application.
Is patching a global object with the current request information an anti-pattern?
I believe it is, because it is in the view of static code analyzer a global state, though it's not. And I as a programmer will not understand how it works without reading the docs carefully. And this has consequences on tests.
Isn't it a good practice to pass the request as an argument to views? I think it's more readable, explicit and easier to debug. And avoids global state.