On Dienstag 07 Oktober 2008, Dirk Meyer wrote: > > That also means that the loop is actually over a "normal iterable"; > > Yes, yield "returns" the result of the InProgress. > > > Still, the asynchronously returned iterable may be itself > > implemented as a coroutine, so without further knowledge/debugging > > my suspicion that this keeps a db connection open may still be true? > > What do you mean?
I mean that the result of query()'s InProgress could be any object, i.e. a list or any other python type that has an __iter__ method, and in fact that __iter__ method could also be a coroutine (correct me if I'm wrong), so it would be possible that during the for-loop over the query results there is still an open DB connection. I was looking for a reason why the --del-media did not remove the record properly anymore when I added the loop for finding the media by name. > > 1) I did not understand this sentence: "Because of this idiom, in Python > > 2.5 the yield statement will raise an exception if there is one while > > Python 2.4 continues and raises the exception when calling get_result." > > What does this want to tell me? This is not about kaa, but about Python, > > right? What are the implications of this when using kaa.*? > > In Python 2.4 the yield code does not return anything. This is why you > have to call get_result(). This will either return the value or raise > the exception from the coroutine. You would think that the following > code would work: > > | async = something() > | yield async > | try: > | result = async.get_result() > | except: > | pass Yes, I would expect it to work, also because it's the example code from http://doc.freevo.org/2.0/SourceDoc/Async. > It does in Python 2.4, but in 2.5 the exception will also be raised in > the yield and you we do not catch this. The code MUST be: > | async = something() > | try: > | yield async > | result = async.get_result() > | except: > | pass Then I think http://doc.freevo.org/2.0/SourceDoc/Async should be changed accordingly. Actually, I think it would be best (easiest to understand, step-by-step) if you put the above explanation below the sentence which I did not understand correctly. I.e. after "Because of this idiom, in Python 2.5 the yield statement will raise an exception if there is one while Python 2.4 continues and raises the exception when calling get_result." you add "That also means that none of the above two variants will work perfectly with both versions, but one would have to wrap the yield in the try..except block:: @kaa.coroutine() def do_something_else(): progress = do_something() try: yield progress # may throw in python 2.5 result = progress.get_result() # may throw in python 2.4 except: print "do_something failed" yield if result == True: yield True yield False Note that the code becomes much more elegant if Python 2.4 compatibility is sacrificed." > > 2) MainThreadCallback: Would it make sense to add the sentence "You could > > also decorate needs_to_be_called_from_main using > > @kaa.threaded("kaa.MAINTHREAD") as mentioned in the previous section."? > > Wouldn't that be the preferred way nowadays? > > Depends. If you have a function is is likely to be called from the > MainThread but at one case you call it from a thread, > MainThreadCallback is the way to go. If you want to be sure, use the > decorator. Keep in mind that the decorator takes some more time. Ah, ok. So maybe add the sentence "Using MainThreadCallback directly, one may circumvent the overhead of @kaa.threaded("kaa.MAINTHREAD") in those cases where the function is called from the main thread already." -- Ciao, / / .o. /--/ ..o / / ANS ooo
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
