On Thu, 2008-08-07 at 22:40 +0200, Dirk Meyer wrote: > Yes, well InProgressCallback is an InProgress object right now. If you > change that I have to check my code if it is broken. But since I still > can yield it, it should work.
I probably didn't want to include InProgressCallback in that list. I was thinking as arguments passed to the constructor, where it makes sense for InProgressAny and InProgressAll, but not for InProgressCallback, which takes a, well, callback. :) But at the very least we'll be able to remove the Signal specific code from its constructor. > > I have a sense that we should provide some means of being able to > > yield any such object directly and not treat it as an InProgress. > > Maybe, suggestions how to do that? The only way I can see is to pass it through some filter that for example sets some flag that the coroutine stepper checks (and clears). Something like: yield self.signals['foo'] vs yield raw(self.signals['foo']) ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
