gh-104254: Document the optional keyword-only "context" argument to Task constructor (GH-104251)
(This was added in 3.11. It was already documented for `create_task()`, but not for `Task()`.)
(cherry picked from commit 4ee2068c34)
Co-authored-by: Itamar Ostricher <itamarost@gmail.com>
Also use `raise TimeOut from <CancelledError instance>` so that the CancelledError is set
in the `__cause__` field rather than in the `__context__` field.
(cherry picked from commit 04adf2df39)
Co-authored-by: Kristján Valur Jónsson <sweskman@gmail.com>
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
gh-85073: Add some missing links to source (GH-99363)
Add some missing links to source from Python docs
(cherry picked from commit 27d8dc2c9d)
Co-authored-by: Stanley <46876382+slateny@users.noreply.github.com>
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>.
(cherry picked from commit fa2d43e518)
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Reason: we were too hasty in deprecating this.
We shouldn't deprecate it before we have a replacement.
(cherry picked from commit 09de8d7aaf)
Co-authored-by: Guido van Rossum <guido@python.org>
Co-authored-by: Thomas Grainger <tagrain@gmail.com>
Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
(cherry picked from commit 6281affee6)
Co-authored-by: Hendrik Makait <hendrik.makait@gmail.com>
Once the task group is shutting down, it should not be possible to create a new task.
Here "shutting down" means `self._aborting` is set, indicating that at least one task
has failed and we have cancelled all others.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
(cherry picked from commit 594c369949)
Co-authored-by: Guido van Rossum <guido@python.org>
After a long deliberation we ended up feeling that the message argument for Future.cancel(), added in 3.9, was a bad idea, so we're deprecating it in 3.11 and plan to remove it in 3.13.
Remove the @asyncio.coroutine decorator
enabling legacy generator-based coroutines to be compatible with async/await
code; remove asyncio.coroutines.CoroWrapper used for wrapping
legacy coroutine objects in the debug mode.
The decorator has been deprecated
since Python 3.8 and the removal was initially scheduled for Python 3.10.
The previous example did not fully showcase the interest of using gather.
Here the example showcases "the result is an aggregate list of returned values".
asyncio.get_event_loop() emits now a deprecation warning when it creates a new event loop.
In future releases it will became an alias of asyncio.get_running_loop().
The issue being resolved is shown in the 3.10 docs (if you select docs for older versions you won't see a visual glitch).
The newer sphinx version that produces the 3.10 docs doesn't treat the backslash to escape things in some situations it previously did.
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.
* Fix as_completed docs to correctly state the function return value.
* Also, improves the general wording of the as_completed documentation.
Co-Authored-By: Rémi Lapeyre <remi.lapeyre@henki.fr>
Co-Authored-By: Kyle Stanley <aeros167@gmail.com>
Co-Authored-By: Yury Selivanov <yury@edgedb.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/18410#issuecomment-628930973) in GH-18410 for context.
Automerge-Triggered-By: @aeros
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>
Miss Islington (bot)