On Mon, Feb 11, 2013 at 10:18 AM, Saúl Ibarra Corretgé firstname.lastname@example.org:
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.)