summaryrefslogtreecommitdiffstats
path: root/Lib/asyncio/tasks.py
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* bpo-36607: Eliminate RuntimeError raised by asyncio.all_tasks() (GH-13971)Andrew Svetlov2019-06-111-6/+32
| | | | | | | If internal tasks weak set is changed by another thread during iteration. https://bugs.python.org/issue36607
* bpo-36999: Add asyncio.Task.get_coro() (GH-13680)Alex Grönholm2019-05-301-0/+3
| | | https://bugs.python.org/issue36999
* bpo-32528: Make asyncio.CancelledError a BaseException. (GH-13528)Yury Selivanov2019-05-271-4/+6
| | | | | | | | | | | | | | | This will address the common mistake many asyncio users make: an "except Exception" clause breaking Tasks cancellation. In addition to this change, we stop inheriting asyncio.TimeoutError and asyncio.InvalidStateError from their concurrent.futures.* counterparts. There's no point for these exceptions to share the inheritance chain. In 3.9 we'll focus on implementing supervisors and cancel scopes, which should allow better handling of all exceptions, including SystemExit and KeyboardInterrupt
* bpo-36932: use proper deprecation-removed directive (GH-13349)Matthias Bussonnier2019-05-211-8/+8
| | | | | | | | .. And update some deprecation warnings with version numbers. https://bugs.python.org/issue36932
* bpo-36921: Deprecate @coroutine for sake of async def (GH-13346)Andrew Svetlov2019-05-161-2/+4
| | | | | | The second attempt. Now deprecate `@coroutine` only, keep `yield from fut` as is. https://bugs.python.org/issue36921
* bpo-35125: remove inner callback on outer cancellation in asyncio shield ↵Romain Picard2019-05-071-2/+8
| | | | | | | | | | | | | | (GH-10340) When the future returned by shield is cancelled, its completion callback of the inner future is not removed. This makes the callback list of inner inner future grow each time a shield is created and cancelled. This change unregisters the callback from the inner future when the outer future is cancelled. https://bugs.python.org/issue35125
* bpo-24638: Improve the error message in asyncio.ensure_future() (#12848)Zackery Spytz2019-05-031-1/+2
|
* bpo-36613: call remove_done_callback if exception (GH-12800)gescheit2019-05-031-1/+2
| | | | | | Call remove_done_callback() in finally block. https://bugs.python.org/issue36613
* asyncio: PendingDeprecationWarning -> DeprecationWarning (GH-12494)Inada Naoki2019-03-221-2/+2
| | | `Task.current_task()` and `Task.all_tasks()` will be removed in 3.9.
* bpo-34970: Protect tasks weak set manipulation in asyncio.all_tasks() (GH-9837)Andrew Svetlov2018-10-131-2/+6
| | | https://bugs.python.org/issue34970
* asyncio/docs: Replace Python 4.0 -> 3.10 (GH-9579)Yury Selivanov2018-09-251-6/+6
|
* bpo-34728: Remove deprecate *loop* argument in asyncio.sleep (GH-9415)João Júnior2018-09-241-3/+16
| | | | | | | | | | | | | | | | * Insert the warn in the asyncio.sleep when the loop argument is used * Insert the warn in the asyncio.wait and asyncio.wait_for when the loop argument is used * Better format of the code * Add news file * change calls for get_event_loop() to calls for get_running_loop() * Change message to be more clear in News * Improve the comments in test_tasks
* bpo-34622: Extract asyncio exceptions into a separate module (GH-9141)Andrew Svetlov2018-09-111-12/+13
|
* bpo-34270: Make it possible to name asyncio tasks (GH-8547)Alex Grönholm2018-08-081-3/+32
| | | Co-authored-by: Antti Haapala <antti.haapala@anttipatterns.com>
* bpo-32751: Wait for task cancellation in asyncio.wait_for() (GH-7216)Elvis Pranskevichus2018-05-291-2/+21
| | | | | | | | | | | | | | | | | | | | | | | Currently, asyncio.wait_for(fut), upon reaching the timeout deadline, cancels the future and returns immediately. This is problematic for when *fut* is a Task, because it will be left running for an arbitrary amount of time. This behavior is iself surprising and may lead to related bugs such as the one described in bpo-33638: condition = asyncio.Condition() async with condition: await asyncio.wait_for(condition.wait(), timeout=0.5) Currently, instead of raising a TimeoutError, the above code will fail with `RuntimeError: cannot wait on un-acquired lock`, because `__aexit__` is reached _before_ `condition.wait()` finishes its cancellation and re-acquires the condition lock. To resolve this, make `wait_for` await for the task cancellation. The tradeoff here is that the `timeout` promise may be broken if the task decides to handle its cancellation in a slow way. This represents a behavior change and should probably not be back-patched to 3.6 and earlier.
* bpo-32684: Fix gather to propagate cancel of itself with return_exceptions ↵Yury Selivanov2018-05-291-1/+13
| | | | (GH-7209)
* bpo-32610: Fix asyncio.all_tasks() to return only pending tasks. (GH-7174)Yury Selivanov2018-05-281-1/+11
|
* bpo-33505: Optimize asyncio.ensure_future by reordering if conditions (GH-6836)jimmylai2018-05-281-5/+5
|
* bpo-33584: Fix several minor bugs in asyncio. (GH-7003)Serhiy Storchaka2018-05-201-1/+1
| | | | | | | | | | | | Fix the following bugs in the C implementation: * get_future_loop() silenced all exceptions raised when look up the get_loop attribute, not just an AttributeError. * enter_task() silenced all exceptions raised when look up the current task, not just a KeyError. * repr() was called for a borrowed link in enter_task() and task_step_impl(). * str() was used instead of repr() in formatting one error message (in Python implementation too). * There where few reference leaks in error cases.
* bpo-32643: Drop support for a few private Task and Future APIs. (#5293)Yury Selivanov2018-01-241-14/+14
| | | | | | | | Specifically, it's not possible to subclass Task/Future classes and override the following methods: * Future._schedule_callbacks * Task._step * Task._wakeup
* bpo-32436: Implement PEP 567 (#5027)Yury Selivanov2018-01-231-8/+16
|
generated by cgit v0.12 at 2025-09-01 19:36:46 (GMT)