durusmail: quixote-users: why pass request object to public functions / methods
why pass request object to public functions / methods
why pass request object to public functions / methods
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-03
2005-01-05
2005-01-03
2005-01-03
why pass request object to public functions / methods
Martin Maney
2005-01-03
On Mon, Jan 03, 2005 at 09:28:20AM -0600, Jason Sibre wrote:
> [... Now I'm wandering off into the woods ...

Shhhh!  We go wabbit huntin'...

> For example, if I were to upgrade my Qx 1.x apps, adding a decorator call
> (@with_request, or some such) to each publishable would be a quicker/less bug
> prone modification than changing the signature of each callable, and adding a
> 'request=get_request()' to it.  Less finger typing.  Not a lot less, granted,
> but it also leaves you less exposed (IMO) to brittleness from object model or
> API changes.  Further, assuming a developer used an approach like this to make
> an app 2.x compatible, they could then go back through the code in piece-meal
> fasion, and weed out the decorators replacing with calls to get_request() as
> needed.  It's not an all-or-nothing approach like subclassing the publisher
> would be.

This is silly.  If you're going to migrate to the new API, then do the
finger typing and be done with it - the decorator is just adding
make-work that you'll throw away later (piece-meal, as you say).  If
you're not, then doing the adaptation by subclassing Publisher is the
single-point change against which any other approach is wasteful of
your fingers' time.  No matter how you do it you're open to having to
make further changes in the face of changes in Quixote's API; arguably
the subclassing approach is the one that does the best job of
insulating you there by keeping the shim(s) in one place.

> I'm not trying to come across as championing decorators, or
> preserving the old model of request handling, just voicing

If I haven't, I'll defend the old model with the explicit request
argument.  As someone said, you can wrap a global in a function call,
but it's still a global.

> observations.  It's all rather hypothetical for me right now anyway,
> as I'm not using python 2.4 or Quixote 2.x on my server, anyway.
> Yet. ;)

Oh, me too.  I'm stuck (1) with Python 2.2 until at least summer, when
I can think about spending more of my "free" time to upgrade the
servers.

(1) not really stuck - it still works great, and I don't really feel
much need for the 2.3 or 2.4 additions - not like list comprehensions,
say, that I really enjoy using day to day.  :-) The one way in which I
do feel stuck is kind of the reverse - I'd love to give Ubuntu a place
on my desk here, but they've dropped Debian's excellent practice of
supporting multiple Python releases (and of course they support 2.3).
So it goes...

--
Self-pity is like sitting there and peeing your pants:
at first, it's warm and comfy, but pretty soon it gets cold
and then it starts to stink.  - anonymous, as is traditional


reply