> "Drew" == Drew Smathers writes:
Drew> On Sat, Jun 6, 2009 at 9:41 PM, Terry Jones wrote:
>> One inconvenience with inlineCallbacks is that you might have some kind
>> of processing you want done no matter how the function returns, or
>> wherever an error occurs. Two solutions here are 1) to
On Sat, Jun 6, 2009 at 9:41 PM, Terry Jones wrote:
> I try to avoid using inlineCallbacks. There are two cases where I will
> happily use it though: when I write a method that would need more than a
> few callback functions, and, more importantly, when the logical flow of a
> method is non-trivial
Hi Maarten
> "Maarten" == Maarten ter Huurne writes:
Maarten> As far as I can see, this decorator could be applied to any
Maarten> function that returns a Deferred, not just to inlineCallbacks.
Yes, that's right, and it could be used in that case if you didn't want to
deal with the deferred
On Sunday 07 June 2009, Terry Jones wrote:
> So I wrote a decorator specifically for inlineCallbacks decorated
> functions:
>
> from twisted.internet import defer
>
> def inlineCallbacksDecorator(callback, errback=defer.passthru):
> def wrap(f):
> def wrapper(*args, **k
I try to avoid using inlineCallbacks. There are two cases where I will
happily use it though: when I write a method that would need more than a
few callback functions, and, more importantly, when the logical flow of a
method is non-trivial (i.e., it depends on the returned values or errors of
sever
