I was a huge opponent of thread locals for a really long time but I finally had to acknowledge that they make things easier instead of harder. And the reason for this is that thread locals exposed are a very explicit thing compared to magic thread locals hidden somewhere in a framework.
The fact that you can do `_app_ctx_stack.top.mydatabase_connection` to get a database connection from anywhere is very helpful. Frameworks that did not expose thread locals still have them. Just special cased for certain things.
How does User.objects.all() get to the current transaction? Correct: a thread local. It's just hidden in the core of the framework. Not having a thread local there is nearly impossible, especially if you need to work with foreign libraries that do not support passing in of information. It's just going to cause a horrible API. (Not for the view case, but for things like database connections)
Flask does not hide things from you. It is very explicit, honest and upfront with everything it's doing. Is it the best solution? I am pretty sure it's not. I do however think that it's a very viable one.
The talk is very advanced and I think I did not make that clear enough from the summary on the website and I learned from that. I also plan on doing a “postmortem” that gives more context into some of the things the talk was mentioning and why it works the way it works.
TL;DR: you can't live without thread locals or you have a horrible API. Flask embraces them on every level and tells you how you can deal with the downsides of it.
I find this to be true in general: Modern software engineering practices are strongly astronauted, and so well ingrained/indoctrinated, that people think you might be crazy for suggesting globals (or thread locals, which are an evolution of globals) are a good idea.
flask seems to make good use of these. For GUI client programming, FLTK does the same thing marvelously - FLTK code is often 3-4 times shorter and simpler than any other GUI API/framework I've used, and it usually performs much better as well.
In general, the "missing piece" that makes globals/TLS at-least-as-usable-as-pass-everything-explicitly, is "push state"/"pop state", which allows you to do reentrant calls -- usually works much, much better than passing the state as an argument everywhere.
edit: I originally wrote "but flask probably doesn't need a state stack", but then I got to the slide that says it does have them :) silly me, apologies.
The fact that you can do `_app_ctx_stack.top.mydatabase_connection` to get a database connection from anywhere is very helpful. Frameworks that did not expose thread locals still have them. Just special cased for certain things.
How does User.objects.all() get to the current transaction? Correct: a thread local. It's just hidden in the core of the framework. Not having a thread local there is nearly impossible, especially if you need to work with foreign libraries that do not support passing in of information. It's just going to cause a horrible API. (Not for the view case, but for things like database connections)
Flask does not hide things from you. It is very explicit, honest and upfront with everything it's doing. Is it the best solution? I am pretty sure it's not. I do however think that it's a very viable one.
The talk is very advanced and I think I did not make that clear enough from the summary on the website and I learned from that. I also plan on doing a “postmortem” that gives more context into some of the things the talk was mentioning and why it works the way it works.
TL;DR: you can't live without thread locals or you have a horrible API. Flask embraces them on every level and tells you how you can deal with the downsides of it.