On 08:12 am, twisted-web@udmvt.ru wrote:
But what about deferring some more complex process, that may have zero to more itermediate results before finishing? What if we are inside that process and have some event, but we are not finished the process? Why can't the consumers of the Deferred be interested in receiving that event too? Why not augment the Deferred for that?
Because Deferreds are intended to be an asynchronous mechanism for control flow. They are the way to return a value which is not yet present. In other words they are an asynchronous version of exit semantics; "return" and "raise". They are very explicitly *not* designed to simultaneously implement asynchronous versions of every other potential control flow - looping, for example, which seems to be what you want. There are other mechanisms for doing those things. For example, if you want to get a stream of data and handle it incrementally, you want to implement an IProtocol or ITransport. Trying to cram all of IProtocol into Deferred is a mistake. If you want some abstraction to support an incremental stream of results with a size known in advance, for example to support drawing a progress bar on an upload or download, then please feel free to propose that as a *separate* mechanism from Deferred, and we can debate its merits and usefulness on its own. But I doubt very much that Deferred should do such a thing itself.