On Mon, Feb 11, 2013 at 11:29 AM, Saúl Ibarra Corretgé firstname.lastname@example.org:
But you were probably calling run_until_complete() without an explicit timeout. In that case, it should not call run() but run_forever(), and it should never raise TimeoutError.
Right, this was actually the case. I'll submit a code review addressing this.
You could still get a TimeoutError if a timeout was given; in that
think you can fix this case by passing call_later() a helper function
sets a nonlocal variable which you then inspect.
Sure, but then what should we do: return like nothing has happened or raise an exception so that the caller knows that the future is not complete?
The same thing as when no timeout is specified. I presume this means returning None. The alternative would be to call future.result() in all cases -- it would raise InvalidStateError, but that doesn't feel very useful. Perhaps this is actually the correct response? What is the reason you have something else that calls stop()?
You could also use a different mechanism, e.g. call cancel() on a Future when the timeout occurs. (But I think that might be less reliable, since
think Tasks can catch cancellations.)
Yeah, that would not work, in my example the task is already started, I don't think cancel() will work midway.
Actually, it may. There is code to throw CancelledError into the generator, in _step(). But I don't think it will necessarily break out of all blocking I/O. (Though it really should -- perhaps this is something useful to add tests for.)