On Mon, Feb 11, 2013 at 10:18 AM, Saúl Ibarra Corretgé <saghul@gmail.com> wrote:

Guido van Rossum wrote:

Yeah, I think the base implementation of run_until_complete is wrong.
I think I didn't have stop() when I coded that.

Could you change it to something that just registers a lambda calling
stop() on the Future, and see if that makes your test case behave
better? (If so, please add a unit test and submit for code review.)

Hum, I guess I'm missing something, but futures don't have a stop() method. The code already calls loop.stop() when the future is done.

Oops, I read your post (and the code) too fast.

What I had in mind was to add a _called to Handler and expose it with a readonly property, so then we could check if handler.called and raise TimeoutError or not. As for raising another exception, maybe it's not such a good idea, since caller can always check future.done() later anyway.

I'm not so keen on that.

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.

You could still get a TimeoutError if a timeout was given; in that case, I think you can fix this case by passing call_later() a helper function that sets a nonlocal variable which you then inspect.

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 I think Tasks can catch cancellations.)

--
--Guido van Rossum (python.org/~guido)