summaryrefslogtreecommitdiffstats
path: root/Lib/asyncio/tasks.py
Commit message (Collapse)AuthorAgeFilesLines
* gh-110961: Fixed asyncio.wait docstring to remove deprecated coroutine ↵Bar Harel2023-10-181-2/+0
| | | | | reference (#111017) Co-authored-by: Kumar Aditya <kumaraditya@python.org>
* gh-109955 : Update state transition comments for asyncio.Task (#109910)Kristján Valur Jónsson2023-09-271-7/+17
| | | Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
* gh-109653: Remove unused imports in the `Lib/` directory (#109803)Alex Waygood2023-09-241-1/+0
|
* Fix patchcheck for `asyncio.tasks` (#108159)Kumar Aditya2023-08-201-9/+9
|
* GH-105684: Require `asyncio.Task` implementations to support `set_name` ↵Kumar Aditya2023-06-131-14/+1
| | | | method (#105685)
* gh-105331: Change `asyncio.sleep` to raise ``ValueError` for nan (#105641)Jay2023-06-121-0/+4
| | | | Co-authored-by: Guido van Rossum <gvanrossum@gmail.com> Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
* gh-97696 Remove unnecessary check for eager_start kwarg (#104188)Jacob Bower2023-05-091-4/+17
| | | | Instead, add docstring to create_eager_task_factory.
* gh-104144: Optimize gather to finish eagerly when all futures complete ↵Itamar Ostricher2023-05-061-1/+12
| | | | eagerly (#104138)
* gh-97696: asyncio eager tasks factory (#102853)Itamar Ostricher2023-05-011-22/+100
| | | | Co-authored-by: Jacob Bower <jbower@meta.com> Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
* GH-100112: avoid using iterable coroutines in asyncio internally (#100128)Kumar Aditya2023-03-161-16/+6
|
* Remove redundant `_ensure_future` in favor of `ensure_future` in `asyncio` ↵Kumar Aditya2023-03-071-6/+2
| | | | (#102398)
* GH-96764: rewrite `asyncio.wait_for` to use `asyncio.timeout` (#98518)Kumar Aditya2023-02-161-48/+29
| | | Changes `asyncio.wait_for` to use `asyncio.timeout` as its underlying implementation.
* gh-100344: Add C implementation for `asyncio.current_task` (#100345)Itamar Ostricher2022-12-221-1/+4
| | | Co-authored-by: pranavtbhat
* gh-93453: No longer create an event loop in get_event_loop() (#98440)Serhiy Storchaka2022-12-061-3/+3
| | | | | | | | | | | | | | | asyncio.get_event_loop() now always return either running event loop or the result of get_event_loop_policy().get_event_loop() call. The latter should now raise an RuntimeError if no current event loop was set instead of creating and setting a new event loop. It affects also a number of asyncio functions and constructors which call get_event_loop() implicitly: ensure_future(), shield(), gather(), etc. DeprecationWarning is no longer emitted if there is no running event loop but the current event loop was set. Co-authored-by: Łukasz Langa <lukasz@langa.pl>
* GH-90985: Revert "Deprecate passing a message into cancel()" (#97999)Guido van Rossum2022-10-071-5/+0
| | | | | Reason: we were too hasty in deprecating this. We shouldn't deprecate it before we have a replacement.
* GH-96704: Add {Task,Handle}.get_context(), use it in ↵Guido van Rossum2022-10-051-0/+3
| | | | | call_exception_handler() (#96756) Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
* gh-90908: Document asyncio.Task.cancelling() and asyncio.Task.uncancel() ↵Łukasz Langa2022-10-011-2/+2
| | | | | | (#95253) Co-authored-by: Thomas Grainger <tagrain@gmail.com>
* gh-94972: document that shield users need to keep a reference to their task ↵Hendrik Makait2022-09-101-2/+9
| | | | | | (#96724) Co-authored-by: Thomas Grainger <tagrain@gmail.com> Co-authored-by: Guido van Rossum <gvanrossum@gmail.com>
* gh-91323: Revert "Allow overriding a future compliance check in asyncio.Task ↵Łukasz Langa2022-08-041-5/+1
| | | | | | (GH-32197)" (GH-95442) This reverts commit d4bb38f82bf18b00db3129031ce4969b6f0caab9.
* bpo-47167: Allow overriding a future compliance check in asyncio.Task (GH-32197)Andrew Svetlov2022-04-011-1/+5
|
* bpo-46829: Deprecate passing a message into Future.cancel() and ↵Andrew Svetlov2022-03-231-0/+5
| | | | | Task.cancel() (GH-31840) 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.
* bpo-34790: Remove passing coroutine objects to asyncio.wait() (GH-31964)Andrew Svetlov2022-03-171-10/+4
| | | Co-authored-by: Yury Selivanov <yury@edgedb.com>
* bpo-47039: Normalize repr() of asyncio future and task objects (GH-31950)Andrew Svetlov2022-03-171-2/+2
|
* bpo-46994: Accept explicit contextvars.Context in asyncio create_task() API ↵Andrew Svetlov2022-03-141-4/+12
| | | | (GH-31837)
* bpo-46995: Deprecate missing asyncio.Task.set_name() for third-party task ↵Andrew Svetlov2022-03-131-1/+4
| | | | | implementations (GH-31838) Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
* bpo-46771: Remove two controversial lines from Task.cancel() (GH-31623)Guido van Rossum2022-02-281-2/+5
| | | | | | | | | | | | | | | Also from the _asyncio C accelerator module, and adjust one test that the change caused to fail. For more discussion see the discussion starting here: https://github.com/python/cpython/pull/31394#issuecomment-1053545331 (Basically, @asvetlov proposed to return False from cancel() when there is already a pending cancellation, and I went along, even though it wasn't necessary for the task group implementation, and @agronholm has come up with a counterexample that fails because of this change. So now I'm changing it back to the old semantics (but still bumping the counter) until we can have a proper discussion about this.)
* bpo-46771: Implement task cancel requests counter (GH-31513)Tin Tvrtković2022-02-241-9/+21
| | | | | This changes cancelling() and uncancel() to return the count of pending cancellations. This can be used to avoid bugs in certain edge cases (e.g. two timeouts going off at the same time).
* bpo-46672: fix `NameError` in `asyncio.gather` if type check fails (GH-31187)Nikita Sobolev2022-02-201-1/+2
| | | Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
* bpo-46752: Add TaskGroup; add Task..cancelled(),.uncancel() (GH-31270)Guido van Rossum2022-02-151-1/+15
| | | | | | | | | | | | | | | | | asyncio/taskgroups.py is an adaptation of taskgroup.py from EdgeDb, with the following key changes: - Allow creating new tasks as long as the last task hasn't finished - Raise [Base]ExceptionGroup (directly) rather than TaskGroupError deriving from MultiError - Instead of monkey-patching the parent task's cancel() method, add a new public API to Task The Task class has a new internal flag, `_cancel_requested`, which is set when `.cancel()` is called successfully. The `.cancelling()` method returns the value of this flag. Further `.cancel()` calls while this flag is set return False. To reset this flag, call `.uncancel()`. Thus, a Task that catches and ignores `CancelledError` should call `.uncancel()` if it wants to be cancellable again; until it does so, it is deemed to be busy with uninterruptible cleanup. This new Task API helps solve the problem where TaskGroup needs to distinguish between whether the parent task being cancelled "from the outside" vs. "from inside". Co-authored-by: Yury Selivanov <yury@edgedb.com> Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
* bpo-26552: Fixed case where failing `asyncio.ensure_future` did not close ↵Kumar Aditya2022-01-281-2/+8
| | | | the coroutine (#30288)
* bpo-46469: Make asyncio generic classes return GenericAlias (GH-30777)Kumar Aditya2022-01-221-2/+2
| | | | | | | | | | | | * bpo-46469: Make asyncio generic classes return GenericAlias * 📜🤖 Added by blurb_it. * Update Misc/NEWS.d/next/Library/2022-01-22-05-05-08.bpo-46469.plUab5.rst Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com> Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
* bpo-37658: Actually return result in race condition (GH-29202)Sam Bull2021-11-291-6/+2
|
* bpo-39529: Deprecate creating new event loop in asyncio.get_event_loop() ↵Serhiy Storchaka2021-04-251-19/+23
| | | | | | (GH-23554) 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().
* bpo-41891: ensure asyncio.wait_for waits for task completion (#22461)Richard Kojedzinszky2020-12-181-1/+4
|
* bpo-42582: Remove asyncio._all_tasks_compat(). (GH-23664)Serhiy Storchaka2020-12-061-24/+0
| | | It was used to implement now removed asyncio.Task.all_tasks().
* bpo-42392: Remove loop parameter from asyncio.tasks and asyncio.subprocess ↵Yurii Karabas2020-11-281-42/+13
| | | | (GH-23521)
* bpo-42392: Remove loop parameter form asyncio locks and Queue (#23420)Yurii Karabas2020-11-241-1/+1
| | | Co-authored-by: Andrew Svetlov <andrew.svetlov@gmail.com>
* bpo-42140: Improve asyncio.wait function (GH-22938)Diogo Dutra2020-11-101-2/+4
| | | | | | | | | | # 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
* bpo-42230: Improve asyncio documentation regarding accepting sets vs ↵Jakub Stasiak2020-11-021-2/+2
| | | | | | | | | | | | | | iterables (GH-23073) People call wait() and as_completed() with various non-set iterables, a list should be the most common but there are others as well[1]. Considering typeshed also documents wait()[2] and as_completed()[3] as accepting arbitrary iterables I think it's a good idea to document the status quo better. [1] https://github.com/aio-libs/aiokafka/pull/672 [2] https://github.com/python/typeshed/blob/620989bac572f30349b95590ebe81a73ce0fe862/stdlib/3/asyncio/tasks.pyi#L161 [3] https://github.com/python/typeshed/blob/620989bac572f30349b95590ebe81a73ce0fe862/stdlib/3/asyncio/tasks.pyi#L40
* bpo-37658: Fix asyncio.wait_for() to respect waited task status (#21894)Elvis Pranskevichus2020-08-261-3/+6
| | | | | | 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.
* bpo-32751: Wait for task cancel in asyncio.wait_for() when timeout <= 0 (#21895)Elvis Pranskevichus2020-08-261-2/+7
| | | | | | 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.
* bpo-37703: improve asyncio.gather documentation regarding cancellation ↵Vinay Sharma2020-07-201-0/+7
| | | | | | | (GH-15312) These changes updates the doc to comprehensively mention the behaviour of gather.cancel() Automerge-Triggered-By: @asvetlov
* bpo-40967: Remove deprecated asyncio.Task.current_task() and ↵Rémi Lapeyre2020-07-021-28/+0
| | | | asyncio.Task.all_tasks() (GH-20874)
* bpo-31033: Improve the traceback for cancelled asyncio tasks (GH-19951)Chris Jerdonek2020-05-181-14/+12
| | | | | 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."
* bpo-31033: Add a msg argument to Future.cancel() and Task.cancel() (GH-19979)Chris Jerdonek2020-05-151-12/+24
|
* bpo-40607: Reraise exception during task cancelation in asyncio.wait_for() ↵romasku2020-05-151-1/+9
| | | | | | | | | | | | | | | (GH-20054) 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>
* bpo-34790: Implement deprecation of passing coroutines to asyncio.wait() ↵Kyle Stanley2019-12-301-0/+6
| | | | (GH-16977)
* bpo-38978: Implement __class_getitem__ for asyncio objects (GH-17491)Batuhan Taşkaya2019-12-071-0/+3
| | | https://bugs.python.org/issue38978
* bpo-38248: Fix inconsistent immediate asyncio.Task cancellation (GH-16330)Yury Selivanov2019-09-251-1/+1
|
* bpo-36373: Deprecate explicit loop in task and subprocess API (GH-16033)Andrew Svetlov2019-09-121-2/+17
|
generated by cgit v0.12 at 2025-04-29 05:45:21 (GMT)