[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:
* 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.
* 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.
Le 2014-04-25 01:45, Clayton Daley a écrit :
*
I am no expert, but the code for inlineCallbacks looks pretty
straightforward, except some special cases handled down the way.
*
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.daley@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
Clayton Daley