We did the same thing to put our authenticated user on the request object, but I still didn't like passing the request around everywhere, so eventually I made some middleware that attached the request as a threadlocal variable, so clients could just refer to the variable if they needed it.
The caveat, of course, is that if you are using anything other than a vanilla CGI-type gateway, you need to make sure to clear out the threadlocal variable at the end of the request. Don't want it getting reused by somebody else. :)
I created my own variable, which I did for two reasons:
First, I didn't want dependencies on Pyramid imports in certain sections of my code.
Second, this comment in the Pyramid docs: This function should be used extremely sparingly, usually only in unit testing code. it’s almost always usually a mistake to use get_current_request outside a testing context because its usage makes it possible to write code that can be neither easily tested nor scripted.
That made me think that they might not have done the due diligence in making sure that my code was safe (which is completely reasonable since they made it explicitly clear they felt that way). Since I knew exactly how I was deploying, I could make it safe.
I believe the point was to unify request.session.flash(…) with things like helpers.flash_success(request,…) such that both flash and flash_success can be methods on the request object.
8 comments
[ 2.6 ms ] story [ 27.5 ms ] threadThe caveat, of course, is that if you are using anything other than a vanilla CGI-type gateway, you need to make sure to clear out the threadlocal variable at the end of the request. Don't want it getting reused by somebody else. :)
First, I didn't want dependencies on Pyramid imports in certain sections of my code.
Second, this comment in the Pyramid docs: This function should be used extremely sparingly, usually only in unit testing code. it’s almost always usually a mistake to use get_current_request outside a testing context because its usage makes it possible to write code that can be neither easily tested nor scripted.
That made me think that they might not have done the due diligence in making sure that my code was safe (which is completely reasonable since they made it explicitly clear they felt that way). Since I knew exactly how I was deploying, I could make it safe.
Before: > def flash_success(request, body, title=''): > request.session.flash({'body': body, 'title': title'})
After: > def flash_success(self, body, title=''): > self.session.flash({'body': body, 'title': title'})