- Python issue 21163: Fix more "Task was destroyed but it is pending!" logs in
tests
- Add test to check that run_until_complete() checks the loop of the future
- Python issue 21163: Fix more "Task was destroyed but it is pending!" logs in
tests
- Add test to check that run_until_complete() checks the loop of the future
TimerHandle
- Uniformize repr() output to format "<Class ...>"
- On Python 3.5+, repr(Task) uses the qualified name instead of the short name
of the coroutine
issue20753 - robotparser tests should not rely upon external resource when not required.
Specifically, it was relying a URL which gave HTTP 403 and used it to assert
it's methods, this changes undoes that and provides a local http server with
similar properties.
Patch contributed by Vajrasky Kok.
Specifically, it was relying a URL which gave HTTP 403 and used it to assert
it's methods, this changes undoes that and provides a local http server with
similar properties.
Patch contributed by Vajrasky Kok.
issue15588 - Correct the quopri module documentation. Mention the correct types
of the parameters on encodestring and decodestring.
Patch by Petri Lehtinen.
coroutine is done: use the first line number of the code object instead of the
current line number of the generator frame.
The name of the coroutine is not enough because many coroutines may have the
same name. It's a common case in asyncio tests for example.
done: use the first line number of the code object instead of the current line
number of the generator frame.
The name of the coroutine is not enough because many coroutines may have the
same name. It's a common case in asyncio tests for example.
raises an exception if the current loop is not None.
Guido van Rossum wrote:
"The behavior that you can set the loop to None (and keep track of it
explicitly) is part of the spec, and this should still be supported even in
debug mode. The behavior that we raise an error if you are caught having
multiple active loops per thread is just a debugging heuristic, and it
shouldn't break code that follows the spec."
exception if the current loop is not None.
Guido van Rossum wrote:
"The behavior that you can set the loop to None (and keep track of it
explicitly) is part of the spec, and this should still be supported even in
debug mode. The behavior that we raise an error if you are caught having
multiple active loops per thread is just a debugging heuristic, and it
shouldn't break code that follows the spec."
