Django-facebook

ncing, you just treat request as you treat datetime. > Singletons are no better - if you dress it up as RequestManager.get_current_request(), it's just as bad. If you don't understand why something is a bad idea, complying with the letter of the law without complying with the spirit doesn't really get you much. I won't do that. That is just a tongue in cheek comment to appease "death to globals" police. > Now I want my programs to do as little as possible and have access to as little as possible. I don't disagree with that but assuming that the request object is available for the request lifecycle is pretty reasonable. > Usually I end up pulling out the values I want inside the view function and calling any helpers using only those values, so I don't pass the request around anyway. You don't pass around request in a general workflow(why would you?). But consider this https://github.com/tschellenbach/Django-facebook. This does a post save signal when a new user registers. I need to send a welcome mail to the user asking him to activate his account. I need request.build_absolute_uri to construct the uri, and guess what, I don't have request in the callback and I don't have a way to obtain it. Now there can be other ways I can solve it - configure sites and generate url using sites; simply have the base url in settings and construct the url by doing a urljoin; may be in some alternate universe, django's reverse generates external url. But the thing is, I have needed access to request object on more than a few occasions. Granted if the callback passed me the request object, it won't have been an issue but it doesn't and I had to resort to thread local middleware to save the request object. > A fourth was that I worked a bunch with both systems and found that adding a parameter to each function along a call path is easy The issue is apis which you haven't wrote. I can always change the packages myself, but I don't want to sync up with upstream for something I see as a small change.