Hello Guido, I ran the test suite of websockets with this patch. It's interesting because the tests stop the event loop in various ways when testing error conditions.
Tests lock in this helper — I can't say I'm surprised: https://github.com/aaugustin/websockets/blob/212fed7/websockets/test_protocol.py#L65-L70 I tried simply skipping the helper: some tests passed, others failed. I don't have time to investigate further right now. In the end I don't have a clear conclusion other than "my tests are too tied to the implementation of asyncio" and "error conditions are hard to test" If someone's interested in replicating this result, all you need is to checkout the websockets repository and run "make test". Best regards, -- Aymeric. > On 18 nov. 2015, at 01:35, Guido van Rossum <[email protected]> wrote: > > In this issue: http://bugs.python.org/issue25593 there's a proposal to > change the semantics of stop(). I'm looking for feedback about whether > this patch would negatively impact anyone. > > The key difference is that if you call stop() multiple times before > run_forever() actually stops, *currently* the next time that > run_forever() is called it will immediately stop again. With the > patch, multiple stop() calls will be redundant -- calling stop() will > only affect the current run_forever() invocation. Note that > run_until_complete() is implemented by combining run_forever() and > stop(). > > (Interestingly, because of the way _run_once() works, if a callback > calls call_soon(X) and then stop(), in the current version X will be > called before run_forever() returns; while with the patch, > run_forever() will return without calling X -- it will be called the > next time run_forever() is called.) > > Thoughts? > > -- > --Guido van Rossum (python.org/~guido)
