Martin Richard

I'm not 100% convinced about a timeout feature. A general-purpose timeout decorator around a coroutine is out of the scope of asynctest (imho), and if we want to tie this...

I really want to avoid dependencies if possible, especially when the library represents ~100-200 LOC. I think it's reasonable to only support asyncio timeouts and assume it's not our job...

Hi, this is a nice feature. I think that the best way to integrate it in asynctest is to use it through the @fail_on decorator: http://asynctest.readthedocs.io/en/latest/asynctest.case.html#asynctest.case.asynctest.fail_on That would allow users...

Hi, I'm quite busy this month, and I can't find enough time to correctly review the opened PRs, thus, sorry for the delays. If you think that we should rework...

I really think this should be implemented with ``@fail_on``: >That would allow users to deactivate this check when they need to: for instance, when a user overrides the default exception...

I don't understand what can be captured via warnings. The first solution we're exploring is relying on a custom exception handler in the loop and relying on gc.collect() to ensure...

Hi, Thanks for you contribution. Can you explain why you want to introduce this feature and in which case it is useful for you? Thanks

It can be useful to have a timeout set on each test, but I feel that your proposal of a decorator targets a use case too broad to be included...

Oh thanks, it's interesting. At first glance, I'd say that since the exception is raised in Future.result(), the stack trace is overridden, while in the second case, re-raising the exception...

Hi, What are you suggesting? Do you think that the examples in the tutorial should use pytest instead of unittest or both? I use the unittest in the tutorial runner...