Quoting Martin Maney :
> On Mon, Jan 03, 2005 at 09:18:25AM -0500, David Binger wrote:
> > My view is that decorator-notation should not be used for any purpose
> > if you would not, in pre-decorator-notation days, have considered
> > doing the equivalent operation.  Using a decorator for classmethod
>
> +1
>
> decorators are the latest hula-hoop


Both very true, but the beauty of approaches like this is:  They don't require
ANYTHING to change on the Quixote side.  It's implementation (or lack of) is
completely restricted to the application side.  It's not vulnerable* to changes
in the Qx object model (which could break subclasses), or the API (which could
break ptl/py callables, as we've already seen).  It's up to the individual
developer to figure out whether to use decorators, use calls to get_request,
etc.

[... Now I'm wandering off into the woods ...  You may want to stop reading
here, unless you're bored. ]

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.  I will grant you that in a truly large app, subclassing the
publisher would be the quickest way to get 2.x compatibility.  Sorta.  You're
really just stalling with that approach, unless you plan on maintaining your
own custom version of Quixote eventually.

I'm not trying to come across as championing decorators, or preserving the old
model of request handling, just voicing 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. ;)


(*) It's not -completely- invulnerable;  changing get_request() to getRequest(),
for example, would break it, but that's probably not likely.  Further, if that
(or a similar change) did happen, it would have to be fixed in exactly one
place in the application's source, if the app was well factored to begin with.