Jason Tackaberry wrote: > On Thu, 2008-08-07 at 21:39 +0200, Dirk Meyer wrote: >> Next try: support classes with a special "magic" __async__ >> function. If hasattr(result, '__async__') this returns an InProgress >> or something else we can return. >> >> if hasattr(result, '__async__'): >> result = result.__async__() > > Yes, that's not a bad idea, given the number of places we're using > InProgress objects, it's nice to give other objects the opportunity to > coerce themselves.
I always wanted to yield a beacon.Query :) > So that would be useful for yielding a signal, and also for > InProgressCallback, InProgressAny, InProgressAll. 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. > Now, there's the problem of changing the semantics of yielding a signal > (or now anything with __async__) in a coroutine. I doubt we're actually > yielding signals now, so it's probably not a problem. I don't think so. IIRC I never "return" a signal in a coroutine > 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? > But I'm ok with not dealing with that just now and waiting until the > time comes, if it ever comes. Right > Let me know if we agree, and I'll make the changes tonight. We do agree. Dischi -- Don't piss me off - I'm running out of places to hide the bodies. ------------------------------------------------------------------------- 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
