On Fri, Feb 22, 2013 at 9:40 AM, Pierre Jaury <pie...@jaury.eu> wrote:
> Hey everyone, > As a matter of fact, this is not the case (the first generation of the > Deferred object will return its actual current state but later > generations will return `None`). Because a Deferred object generation > from an inlineCallbacks-decorated function does not allow for anything > but waiting for the Deferred object to fire and returning its state, it > would probably not harm to forward this state to the next callback as > well. Something like: > ... > would probably do the trick and allow for complex scenarios where the > same Deferred object is generated multiple times by different functions > before being fired. > > As I am not an accomplished Twisted hacker, I cannot say if this kind of > change would harm or break any code out there. Yet it seems to me that > according to inlineCallbacks behavior, it is very unlikely to have any > consequence at all but improving (extending at least) inlineCallbacks > behavior. > I think it's a reasonable change to make, and I don't foresee any problems with it, so I think it's fine to submit a bug about it. But I do question the architecture that needs to make use of it. I would probably avoid scenarios like that in my own code. -- Christopher Armstrong http://radix.twistedmatrix.com/ http://planet-if.com/
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
