Guido van Rossum added the comment: Yeah, I've thought about changing the stop() mechanism too. It might mean that some callbacks will be executed that are currently skipped though, if your proposal is to run all callbacks in self._ready (excluding new ones) and then just exit if the stop flag is set. I worry about how this would violate expectations. We should be able to get away with this, because PEP 3156 is carefully vague about exactly how soon the loop will stop: it promises that callbacks scheduled *before* stop() was called will run before the loop exist -- but it makes no promises either way about callbacks schedule after stop() is called.
A less intrusive change to stop() would be to somehow mark the point in self._ready where stop is called, so stopping at the same point as with the old algorithm, except for one difference: if you call stop() multiple times, it currently leaves extra "markers" in self._ready, which must be consumed by calling run_forever() multiple times. This proposal would change the semantics of that case. Again, I don't think PEP 3156 prevents us from doing that. But I still think those callbacks should be fixed (Alexander's original fix, extended to a few other callbacks that use fut.cancelled()). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25593> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
