Not really global variables. I would analogize it to dynamic variables from Lisp, which are a feature I wish every language had. I strongly disagree it's a hack or gets in the way. Having access to the request from anywhere without explicitly passing it around is really useful.
OK, fair point, I used a wrong term here. So instead of global variables we have dynamic modules that represent a stateful context object which is different depending on where they are imported and when. Very un-Pythonic, and honestly I'd prefer global variables here. :-/
>different depending on where they are imported and when
Er, no. Their value depends on where in the callstack you read it, not on where/how they're imported. They're like global variables but with thread locality, and with a stack of values.
The context local request object is nice (once you accept it), but it definitely complicates the testing story. Whether that is a worthwhile trade-off depends on how many tests you write I suppose.
Not really global variables. I would analogize it to dynamic variables from Lisp, which are a feature I wish every language had. I strongly disagree it's a hack or gets in the way. Having access to the request from anywhere without explicitly passing it around is really useful.