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)

Reply via email to