On Sat, Jul 13, 2002 at 08:18:38PM -0500, Glyph Lefkowitz wrote:
On Sun, 14 Jul 2002 02:55:49 +1000, Andrew Bennetts <andrew-twisted@puzzling.org> wrote:
DeferredList takes care of this nicely, so long as it works.
Rather than adding a whole new class to defer.py, maybe you could make the other deferred's errback get called by the first one?
That's what I'm currently attempting to do, and it's messy. You really want to make sure that adding the errback to call the other Deferred's errbacks doesn't interfere in the normal chain of processing for that errback, so you need to muck around with gunk like "lambda e: otherDeferred.errback(e) or e". Worse than that, with 3 or more Deferreds ordering becomes hell... if you have Deferreds A, B and C, then A should call B & C, B should call A & C, and C should call A & B. I don't know of a clean way to arrange that. Plus, it's what I'm currently trying to do, and it doesn't work. Doubtless this is a bug in how I'm doing it, but that's just another argument for having a class to do it for me.
I realise I'm probably too late to get this into 0.19.0, but I'm wondering what the right way to provide this is: - new class in defer.py (what would it be called?),
"DeferOneOrMany", maybe? Tough thing to name. This is probably the right approach, though; consider that there are cases where one error might be all you need, or one success. In those cases you don't want to get a list as your callback, you just want to get the one value.
Well, I *definitely* want all callbacks, or just one errback. I can imagine that only one either could be useful too, though. Taking this approach, suddenly we have two new classes to name, both similar and yet and different to DeferredList: all callbacks or one errback, and one callback or one errback, vs. the current all callbacks and all errbacks.
- change the behaviour of DeferredList to do what I want, or
Definitely not!! There are plenty of cases where you need _all_ the operations to complete regardless of their status of completion.
Ok. I wasn't sure if this aspect of its functionality was in use, though I guessed it probably was.
- add a flag to the current DeferredList so it can do either behaviour?
As I said above, the behavior is really different; the types of the signatures for your callbacks will be different. That says "different class" to me.
I'm not so sure. Would it be so bad to be able to do this: dl = DeferredList([d1, d2, ...], fireOnOneCallback=1, fireOnOneErrback=1) This way we can get all four variations for free, without having to think of distinct and non-confusing names for them. Of course, "fireOnOneCallback" is a pretty ugly name for a keyword argument. This approach, despite the way it can change the signature of callback and/or errback, seems more general to me. Or is the way you envisage that "DeferOneOrMany" would behave? -Andrew.