Hello, With this change, the patch for issue 25593 no longer causes problems :-)
I believe it makes the websockets tests more robust and predictable as well. Thank you! -- Aymeric. > On 18 nov. 2015, at 16:42, Guido van Rossum <gu...@python.org> wrote: > > The way to fix that test helper is: > > loop.call_soon(loop.stop) > loop.run_forever() > > On Wed, Nov 18, 2015 at 1:00 AM, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: >> 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 <gu...@python.org> 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) >> > > > > -- > --Guido van Rossum (python.org/~guido)
