* Terry Jones <terry@jon.es> [2008-11-03 01:16:50 +0100]:
I usually solve this kind of problem like this:
d = aFuncReturningADeferred() d.addCallback(MyClass) d.addCallback(cb)
See? I knew there'd be a 3-line solution somewhere :-)
That's very cute, I'd never have thought of that... Python is so nice.
My (weak?) response is that your solution isn't quite so general. What if I want __init__ to generate the deferred based on its args, or on the result of other functions called based on its args? Yes, I can do all that work before using your lovely d.addCallback(MyClass), but then the logic of what the class does is starting to leak out into the code that should be calling the class. And you can't encapsulate THAT code into another class, because its __init__ would in turn have to return a deferred.
You can, however, encapsulate it into a classmethod or free function that you call to get an instance of MyClass. This is a pattern often seen when there are various ways to build an instance of some class; you'll have a very basic __init__, and then a bunch of factory functions or classmethods that do more complicated work before passing the results in to the class's constructor.
BTW, I sometimes have the feeling that Deferreds are like how M$ characterizes the GPL. Viral. Once you call anything creating a Deferred, you're hooked - whatcha gonna do with that Deferred boy? Take one sip of the Deferred Kool Aid and the next thing you know you're on a drip.
Just wait until you start trying to combine iterators and deferreds ;) -- mithrandi, i Ainil en-Balandor, a faer Ambar