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.
Global request context - anti-pattern?
design patterns;python;anti patterns;flask