[apologize in advance if this creates threading issues as I picked digests when I signed up not realizing it would make it difficult to reply to threads]
Sorry I wasn't more clear. My thought is to write a version that uses the same @inlineCallback name and supports the same syntax (to eliminate the need to rewrite code). However, I don't mean the synchronous version to actually use deferreds at all. All I want the synchronous version to do is "ignore" the yields (likely by sending the output right back in after the block clears)... and treat the returnValue() as a return. That way code written in the @inlineCallback syntax can be used by a synchronous or asynchronous consumer. Clayton Daley On Thu, Apr 24, 2014 at 8:14 PM, pierre at jaury.eu wrote: > Le 2014-04-25 01:45, Clayton Daley a écrit : >* I imagine rewriting this to the following: *> >* @classmethod *>* @inlineCallbacks *>* def from_id(cls, id): *>* doc = yield db.get_document(id) # blocking/async db call *> >* self = cls._new_document(doc) # always synchronous *>* yield self.__init__() # blocking/async call *>* returnValue(self) *> >* places. I've read that the @inlineCallback code is complicated so I *>* figured I'd run the idea by the experts before diving down that rabbit *>* hole. * I am no expert, but the code for inlineCallbacks looks pretty straightforward, except some special cases handled down the way. >* Does anyone see any obvious pitfall? I'm happy to do the legwork *>* to try and build it, but I'd also welcome any pointers from your (no *>* doubt extensive) experience writing the twisted version. * I would mostly argue about a semantic problem. inlineCallbacks help asynchronous code *look* like synchronous code thanks to the sequential writing. It is however essentially asynchronous and does return a Deferred. I do not see any immediate technical pitfall here. I would however be very careful and double think my design if I were to use Deferred objects as part of a blocking process. kaiyou. On Thu, Apr 24, 2014 at 7:45 PM, Clayton Daley <clayton.da...@gmail.com>wrote: > I have a modular application that communicates over RPC connections (with > both sync and async server/clients available). I want to migrate some of > the modules over to Twisted. Currently, all modules inherit important > utility functions from a parent class. On paper, I now need two versions > of this parent class (synchronous & asynchronous) to be inherited by > modules of the respective types. > > I'm looking for ways to maximize the common code between the two versions > of the parent object. One that comes to mind (motivating the subject of > this post) would be to write a synchronous interpreter for @inlineCallback > calls. For example, here's a synchronous factory function from the parent > class (already partly reconfigured to be friendly to my idea): > > @classmethod > def from_id(cls, id): > doc = db.get_document(id) # blocking db call > self = cls._new_document(doc) # synchronous initialization stuff > self.__init__() # module init code is custom and may block > return self > > I imagine rewriting this to the following: > > @classmethod > @inlineCallbacks > def from_id(cls, id): > doc = yield db.get_document(id) # blocking/async db call > self = cls._new_document(doc) # always synchronous > yield self.__init__() # blocking/async call > returnValue(self) > > Assuming the db connector and init function are appropriate to the > environment, my gut reaction is that this could (when combined with a > synchronous implementation of the decorator) run correctly in both places. > I've read that the @inlineCallback code is complicated so I figured I'd run > the idea by the experts before diving down that rabbit hole. Does anyone > see any obvious pitfall? I'm happy to do the legwork to try and build it, > but I'd also welcome any pointers from your (no doubt extensive) experience > writing the twisted version. > > Thanks in advance! > > Clayton Daley >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
