Re: [Twisted-Python] sleeping in inlineCallbacks
Hi Brian Forgive me for butting in, but.... why :-) Importing the reactor is no big deal, and if you use task.deferLater, apart from not having to write any code you also have the advantage of being able to pass it a result that the deferred will be called with. For this reason you can also put a task.deferLater result into a callback chain to achieve an async sleep and it will duly pass the result along. E.g.: from twisted.internet import reactor, task, defer d = somethingReturningADeferred() d.addCallback(lambda x: task.deferLater(reactor, 5.0, defer.passthru, x)) Terry
Hi Brian
Forgive me for butting in, but.... why :-)
Helpful butting in is more than fine..
Ahh, I see. I saw the signature of deferLater and the Clock class in task and I thought that I would have to create a Clock instance by hand. That I can simply use the reactor (which of course is already imported and running in my code) simplifies the usage of deferLater. Thanks! But, even with this, I do like the flow and readability of code that uses sleep like this: @inlineCallbacks def f(): result1 = yield somethingDeferred() yield sleep(1.0) result2 = yield anotherDeferred(result2) Rather than the way that deferLater looks: @inlineCallbacks def f(): result1 = yield somethingDeferred() result2 = yield task.deferLater(reactor, 1.0, anotherDeferred, result2) But, the difference at this point is entirely aesthetic. One question though - can someone explain the need/usage cases for task.Clock and the other things in task? Cheers, Brian
On Thu, Oct 29, 2009 at 8:38 PM, Brian Granger <ellisonbg.net@gmail.com> wrote:
One question though - can someone explain the need/usage cases for task.Clock and the other things in task?
Clock is a "fake" IReactorTime implementation; as the docstring says, it is intended for writing unit tests where you want control over the behaviour of the clock, rather than using the real time source. As for the other things... LoopingCall repeatedly runs a callable at a certain interval, coiterate takes a generator and iterates it cooperatively (returning control back to the reactor between iterations), and cooperate is a new-and-improved version of coiterate which I haven't looked at yet. -- mithrandi, i Ainil en-Balandor, a faer Ambar
Hi Brian
Forgive me for butting in, but.... why :-)
Helpful butting in is more than fine..
Ahh, I see. I saw the signature of deferLater and the Clock class in task and I thought that I would have to create a Clock instance by hand. That I can simply use the reactor (which of course is already imported and running in my code) simplifies the usage of deferLater. Thanks! But, even with this, I do like the flow and readability of code that uses sleep like this: @inlineCallbacks def f(): result1 = yield somethingDeferred() yield sleep(1.0) result2 = yield anotherDeferred(result2) Rather than the way that deferLater looks: @inlineCallbacks def f(): result1 = yield somethingDeferred() result2 = yield task.deferLater(reactor, 1.0, anotherDeferred, result2) But, the difference at this point is entirely aesthetic. One question though - can someone explain the need/usage cases for task.Clock and the other things in task? Cheers, Brian
On Thu, Oct 29, 2009 at 8:38 PM, Brian Granger <ellisonbg.net@gmail.com> wrote:
One question though - can someone explain the need/usage cases for task.Clock and the other things in task?
Clock is a "fake" IReactorTime implementation; as the docstring says, it is intended for writing unit tests where you want control over the behaviour of the clock, rather than using the real time source. As for the other things... LoopingCall repeatedly runs a callable at a certain interval, coiterate takes a generator and iterates it cooperatively (returning control back to the reactor between iterations), and cooperate is a new-and-improved version of coiterate which I haven't looked at yet. -- mithrandi, i Ainil en-Balandor, a faer Ambar
participants (4)
-
Brian Granger -
exarkun＠twistedmatrix.com -
Terry Jones -
Tristan Seligmann