Well, I think they are actually the same. In the gist I posted earlier I called loop.stop(), I didn't raise the exception inside the task, and loop.stop() will call call_soon so the actual raising will happen in the context on _run_once unless I'm mistaken.
I think there are actually two cases: where stop() is called from the
task given to run_until_complete(), or from another task. In the former
case, because the exception bubbles out of the task's coroutine, the
task will be marked as done (and its exception set to _StopError) -- at
least I think so. In the latter case, the task will still be runnable,
and it will continue to run when the event loop is started again. (Hm...
maybe run_forever() should be called start(), to match stop()?)
I think your unittest only tests the former case.
Here is an updated simple test with it's output: https://gist.github.com/saghul/4758151I think the current behavior is ok, it the user really wants to check if the future was actually completed she can check with done(), if she saved the future in a variable, that is.
I'm not sure what run_until_complete() should return in the latter case.
In fact it makes me doubt the behavior of run_until_complete() in
general. Maybe it should return the Future (although that's kind of
redundant)? Or an enum indicating what happened? (Cases would be result,
exception, timeout, running -- and maybe cancelled?)
My other preferred approach would be to raise an exception, since I consider this an exceptional case: I told the loop to run until this future is completed so I expect that to happen. Since it didn't, NotCompletedError (or something alike) sounds good to me.