Co-authored-by: Thomas Grainger <tagrain@gmail.com>
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
(cherry picked from commit 8fb94893e4)
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
The docstring for `BufferedProtocol` states that the class is still an "experimental API", but it has been considered stable since 3.8.
(cherry picked from commit 1d81fdc4c0)
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
(cherry picked from commit 3e43fac250)
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
Fix typos in the Lib directory as identified by codespell.
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
(cherry picked from commit 745c9d9dfc)
Automerge-Triggered-By: GH:JulienPalard
Deprecation warnings about the loop argument were incorrectly emitted
in cases when the loop argument was used inside the asyncio library,
not from user code.
(cherry picked from commit 17ef4319a3)
Co-authored-by: Richard Kojedzinszky <rkojedzinszky@users.noreply.github.com>
Co-authored-by: Richard Kojedzinszky <rkojedzinszky@users.noreply.github.com>
This is a trivial refactor in preparation for a fix for bpo-38323.
(cherry picked from commit 66d3b589c4)
Co-authored-by: Chris Jerdonek <chris.jerdonek@gmail.com>
GH- Improve asyncio.wait function
The original code creates the futures set two times.
We can create this set before, avoiding the second creation.
This new behaviour [breaks the aiokafka library](https://github.com/aio-libs/aiokafka/pull/672), because it gives an iterator to that function, so the second iteration become empty.
Automerge-Triggered-By: GH:1st1
(cherry picked from commit 7e5ef0a571)
Co-authored-by: Diogo Dutra <diogodutradamata@gmail.com>
The overflow occurs under some circumstances when a task or future
recursively returns itself.
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
(cherry picked from commit 42d873c63a)
Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
Fix a race condition in the call_soon_threadsafe() method of
asyncio.ProactorEventLoop: do nothing if the self-pipe socket has
been closed.
(cherry picked from commit 1b0f0e3d7d)
Co-authored-by: Victor Stinner <vstinner@python.org>
* bpo-41696: Fix handling of debug mode in asyncio.run
This allows PYTHONASYNCIODEBUG or -X dev to enable asyncio debug mode
when using asyncio.run
* 📜🤖 Added by blurb_it.
Co-authored-by: hauntsaninja <>
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
(cherry picked from commit 0770ad948c)
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Stopping and restarting a proactor event loop on windows can lead to
spurious errors logged (ConnectionResetError while reading from the
self pipe). This fixes the issue by ensuring that we don't attempt
to start multiple copies of the self-pipe reading loop.
(cherry picked from commit ea5a6363c3)
Co-authored-by: Ben Darnell <ben@bendarnell.com>
Co-authored-by: Ben Darnell <ben@bendarnell.com>
Currently, if `asyncio.wait_for()` itself is cancelled it will always
raise `CancelledError` regardless if the underlying task is still
running. This is similar to a race with the timeout, which is handled
already.
(cherry picked from commit a2118a1462)
Co-authored-by: Elvis Pranskevichus <elvis@magic.io>
When I was fixing bpo-32751 back in GH-7216 I missed the case when
*timeout* is zero or negative. This takes care of that.
Props to @aaliddell for noticing the inconsistency.
(cherry picked from commit c517fc7121)
Co-authored-by: Elvis Pranskevichus <elvis@magic.io>
Fix grammar in BaseTransport.close docstring.
https://bugs.python.org/issue41572
Signed-off-by: Cleber Rosa <crosa@redhat.com>
(cherry picked from commit 1afb42cfa8)
Co-authored-by: Cleber Rosa <cleber.gnu@gmail.com>
asyncio.AbstractEventLoop.run_in_executor should be a method that returns an asyncio Future, not an async method.
This matches the concrete implementations, and the documentation better.
(cherry picked from commit 29f84294d8)
Co-authored-by: James Weaver <james.barrett@bbc.co.uk>
On Windows, fix asyncio recv_into() return value when the socket/pipe
is closed (BrokenPipeError): return 0 rather than an empty byte
string (b'').
(cherry picked from commit 602a971a2a)
Co-authored-by: Victor Stinner <vstinner@python.org>
These changes updates the doc to comprehensively mention the behaviour of gather.cancel()
Automerge-Triggered-By: @asvetlov
(cherry picked from commit d42528a3a2)
Co-authored-by: Vinay Sharma <vinay04sharma@icloud.com>
When I wrote the documentation for `asyncio.to_thread()`, I mistakenly assumed that `return await loop.run_in_executor(...)` within an async def function would return a Future. In reality, it returns a coroutine.
This likely won't affect typical usage of `asyncio.to_thread()`, but it's important for the documentation to be correct here. In general, we also tend to avoid returning futures from high-level APIs in asyncio.
(cherry picked from commit 2b201369b4)
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
Allows contextvars from the main thread to be accessed in the separate thread used in `asyncio.to_thread()`. See the [discussion](https://github.com/python/cpython/pull/20143GH-discussion_r427808225) in GH-20143 for context.
Automerge-Triggered-By: @aeros
(cherry picked from commit 0f56263e62)
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
Implements `asyncio.to_thread`, a coroutine for asynchronously running IO-bound functions in a separate thread without blocking the event loop. See the discussion starting from [here](https://github.com/python/cpython/pull/18410GH-issuecomment-628930973) in GH-18410 for context.
Automerge-Triggered-By: @aeros
(cherry picked from commit cc2bbc2227)
Co-authored-by: Kyle Stanley <aeros167@gmail.com>
When an asyncio.Task is cancelled, the exception traceback now
starts with where the task was first interrupted. Previously,
the traceback only had "depth one."
Currently, if asyncio.wait_for() timeout expires, it cancels
inner future and then always raises TimeoutError. In case
those future is task, it can handle cancelation mannually,
and those process can lead to some other exception. Current
implementation silently loses thoses exception.
To resolve this, wait_for will check was the cancelation
successfull or not. In case there was exception, wait_for
will reraise it.
Co-authored-by: Roman Skurikhin <roman.skurikhin@cruxlab.com>
Łukasz Langa