On 2008-01-17 14:35, Dirk Meyer wrote:
>> But this doesn't work in the case where the decorated function doesn't
>> yield anything but just returns something.
>
> That is ugly anyway.
There is an argument to be made there, granted. You might say that if
the decorated function is not a generator, we should raise a ValueError
or something. This would make your earlier idea of deferring .next()
work more cleanly, but again I don't want to defer execution unless it's
necessary since it needlessly introduces execution latency.
So I still favor emit_deferred(). And if that's available, supporting
the case where the decorated function returns instead of yielding is
easy, and there is no ambiguity in what the caller wants to do in this
case, so it makes sense to support it.
> I hope you can. Doing the async stuff was not easy to test. :)
I know, which is why we should be synchronous where possible.
> InProgress is a different kind of Signal. We will _always_ have only
> one call back. So in fact, connect acts like connect_once. So if the
> signal already fired, connect should not connect but call the callback
> right now.
So we can put that logic into InProgress, or into Signal. If we put it
in Signal it's reusable in other situations. (I seem to recall needing
this type of thing in a case that had nothing to do with InProgress.)
> Nice. But that would move our target platform to 2.5. Do we want to do
> that? I agree, it looks much nicer this way.
Well, I wasn't actually suggesting that, but we may want to consider
it. Here are the facts:
1. Python 2.5 was released in September 2006, and was included in
Fedora 7 (released May 2007) and Ubuntu Feisty (released April 2007).
2. Freevo 2 will not be out for at least a year.
3. Freevo 1.x uses kaa.base and targets Python 2.3 according to the
wiki (Duncan, is this still true? Does 1.8 not use decorators?)
I think the only python 2.4 feature we're using right now are decorators
which I think aren't actually being used inside kaa proper. It should
be possible to provide backward compatibility for the old idiom while
supporting the new one on python 2.5. In other words, this will work on
Python 2.5:
@kaa.yield_execution()
def foo():
try:
result = yield some_async_func()
except Exception:
...
While this would work on both python 2.4 and 2.5:
@kaa.yield_execution()
def foo():
def handle_exception(type, value, tb):
...
ip = some_async_func()
ip.exception.connect(handle_exception)
yield ip
result = ip()
...
What's rather nice is that some_async_func() can be either a
yield_execution or execute_in_thread decorated function and behave the
same way.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Freevo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
