[Twisted-Python] DeferredList.addDeferred behaviour

Andrew Bennetts andrew-twisted at puzzling.org
Wed Feb 18 20:32:45 EST 2004

On Wed, Feb 18, 2004 at 09:37:53PM -0300, RITA Y/O RODRIGO DIAZ Y/O BENENSON wrote:
> I have been playing with DeferredList if found that his behaviour was not
> what I expected,
> >>> dfl = DeferredList([])
> >>> print dfl.called
> True
> >>> dfl.addDeferred(d)
> >>> d.called
> 0
> >>> print dfl.called
> True
> The workaround it to first create the list of deferred instance and then
> instanciate with it the DeferredList. But what sense does have the
> addDeferred method then ? I this behaviour what is supposed to be ?

It's not clear to me what the right behaviour here is -- if a DeferredList
has some number of Deferreds that have all been called, then of course the
DeferredList should be marked as called, too.  But if you then add an
uncalled Deferred to it, that sounds like a bug.  I'd be inclined to make
DeferredList.addDeferred raise an exception in this case -- "In the face of
ambiguity, refuse the temptation to guess." (although perhaps a warning
would be better for a release or two, for backwards compatibility)

I'm tempted to go even further and just deprecate addDeferred.  I can't see
a good use-case for it, and grep of the entire Twisted code base finds no
uses outside of the test suite.  It's not obvious or intuitive exactly what
addDeferred should do in at least this situation, and probably others.  I
can't think of any situation where addDeferred is required, and I think
calling it with the final list upfront is more readable, anyway.

Can anyone offer reasons why addDeferred should stay?  Donovan -- CVS says
you added it, can you remember why?  Is anyone using it?


More information about the Twisted-Python mailing list