[Web-SIG] Alternative to threading.local, based on the stack

Iwan Vosloo iwan at reahl.org
Mon Jul 7 15:10:12 CEST 2008


On Mon, 2008-07-07 at 13:48 +0100, Matt Goodall wrote:
> Iwan Vosloo wrote:
> > On Fri, 2008-07-04 at 13:39 +0100, Matt Goodall wrote:
> >> The ideal solution is, of course, to pass everything around to whatever
> >> needs it. However, there's really tedious at times.
> >>
> >> Whatever the architecture of the web server there is always a request
> >> or, in case of WSGI, an env dict. Therefore, request-scope objects
> >> should be associated with the request.
> > 
> > True, but even passing a request or env dict around to everyone gets
> > tedious don't you think?
> 
> Yes, it can be tedious but I believe explicit arg passing is necessary
> to make code readable, testable and reusable.
> 
> If it's web-related code then give it the request, it will almost
> certainly need it. Otherwise, don't.
> 
> I would even advocate extracting request-scope objects, e.g. a database
> connection, the current user, etc, as early as possible and passing them
> around explicitly (along with the request, if necessary).

I understand the explicit passing arguments. However, if you pass a
particular argument to _each and every_ little method,
readability/testability/reusability are adversely affected too. And
sometimes you need to pass, say the request, to the strangest little
methods just because one of them somewhere needs to do something with
the request which you did not anticipate.  It may not even be logically
related to what that method does. Or, worse, it may be that you sit with
a bunch of polymorphic methods, and one of their implementations needs
to have a request - forcing you to add a request parameter to all of
them.

Bottom line for me is that if you add, say "request" to a method
signature, it must make sense from a caller's perspective to have to
give a request. (And I want to add: to give a request to a method named
xxx.)  Otherwise the interface of the method contains illogical bits
necessitated by its implementation.

Isn't that bad too?

-i



More information about the Web-SIG mailing list