Glyph,
Thank you very much for your response, it has provided me with material that will help me take a big step in my Twisted education. > > Deferreds are not about breaking your work up into steps to save time. > They're about breaking it up so that different systems can deal with > the > same asynchronous event in their own way. > > For example, let's say you're working on a REST client that deals with > invoices. The server gives you data at a particular URL and you want > to > convert it into an "Invoice" instance. > (snip) This whole section of your answer really helped me get a handle on a deferred, well beyond the "promise that a function will have a result later". J I was thinking kind of monolithically about how to use deferreds, in that if I was writing everything why would I break it up? However, the real case is more along the lines of what you said in your answer; more than likely the eventual total behavior is made up of a string of smaller behaviors 'glued' together by the deferred. And these other behaviors would be code generated by others in my group or libraries. (snip) > > If you actually wanted to interleave Deferred callbacks like that it > would be tricky. But if you just want interleaved callbacks, use > Cooperator as I mentioned above :). > This reference to the Cooperator really helped me out, I just didn't know what to look for in the Twisted system to do what I wanted with co-operating state machines. I did build a little prototype using deferreds that does provide the behavior I was after, but it was awkward at best to set up. I felt like there should be something more elegant, and the Cooperator looks like exactly what I need. I'm going to try and set up a prototype to experiment with so I understand it more. Again, thanks for your reply and help! Doug
_______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
