summaryrefslogtreecommitdiffstats
path: root/Lib/test/test_asyncio/test_tasks.py
Commit message (Collapse)AuthorAgeFilesLines
* bpo-45011: Fix test_asyncio without C module _asyncio (GH-27968)Miss Islington (bot)2021-08-261-2/+5
| | | | | | Co-authored-by: Łukasz Langa <lukasz@langa.pl> (cherry picked from commit 7dc505b8655b3e48b93a4274dfd26e5856d9c64f) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* bpo-39529: Deprecate creating new event loop in asyncio.get_event_loop() ↵Serhiy Storchaka2021-04-251-111/+231
| | | | | | (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-42392: Remove loop parameter from asyncio.tasks and asyncio.subprocess ↵Yurii Karabas2020-11-281-60/+35
| | | | (GH-23521)
* bpo-42140: Improve asyncio.wait function (GH-22938)Diogo Dutra2020-11-101-0/+24
| | | | | | | | | | # 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-37658: Fix asyncio.wait_for() to respect waited task status (#21894)Elvis Pranskevichus2020-08-261-0/+16
| | | | | | 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-0/+31
| | | | | | 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-40967: Remove deprecated asyncio.Task.current_task() and ↵Rémi Lapeyre2020-07-021-47/+1
| | | | asyncio.Task.all_tasks() (GH-20874)
* bpo-40696: Fix a hang that can arise after gen.throw() (GH-20287)Chris Jerdonek2020-05-221-3/+36
| | | | | | | | This updates _PyErr_ChainStackItem() to use _PyErr_SetObject() instead of _PyErr_ChainExceptions(). This prevents a hang in certain circumstances because _PyErr_SetObject() performs checks to prevent cycles in the exception context chain while _PyErr_ChainExceptions() doesn't.
* bpo-31033: Improve the traceback for cancelled asyncio tasks (GH-19951)Chris Jerdonek2020-05-181-22/+114
| | | | | 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-25/+141
|
* bpo-40607: Reraise exception during task cancelation in asyncio.wait_for() ↵romasku2020-05-151-4/+51
| | | | | | | | | | | | | | | (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-29587: Make gen.throw() chain exceptions with yield from (GH-19858)Chris Jerdonek2020-05-131-0/+27
| | | | | | | | | | | | The previous commits on bpo-29587 got exception chaining working with gen.throw() in the `yield` case. This patch also gets the `yield from` case working. As a consequence, implicit exception chaining now also works in the asyncio scenario of awaiting on a task when an exception is already active. Tests are included for both the asyncio case and the pure generator-only case.
* bpo-34790: Implement deprecation of passing coroutines to asyncio.wait() ↵Kyle Stanley2019-12-301-5/+19
| | | | (GH-16977)
* bpo-38248: Fix inconsistent immediate asyncio.Task cancellation (GH-16330)Yury Selivanov2019-09-251-0/+4
|
* bpo-34037: test_asyncio uses shutdown_default_executor() (GH-16284)Victor Stinner2019-09-191-0/+2
|
* bpo-36373: Deprecate explicit loop in task and subprocess API (GH-16033)Andrew Svetlov2019-09-121-7/+8
|
* bpo-38107: Replace direct future and task contructor calls with factories in ↵Andrew Svetlov2019-09-111-12/+12
| | | | asyncio tests (GH-15928)
* bpo-36373: Deprecate explicit loop parameter in all public asyncio APIs ↵Emmanuel Arias2019-09-101-9/+16
| | | | | | | | | | | | | | | [locks] (GH-13920) This PR deprecate explicit loop parameters in all public asyncio APIs This issues is split to be easier to review. Third step: locks.py https://bugs.python.org/issue36373
* bpo-37323: Suppress DeprecationWarning raised by @asyncio.coroutine (GH-14293)Xtreak2019-06-221-1/+3
| | | | | | When the test is ran with `PYTHONWARNINGS=error` the environment variable is passed to the python interpreter used in `assert_python_ok` where `DeprecationWarning` from `@asyncio.coroutine` is converted into an error. Ignore the `DeprecationWarning` in `assert_python_ok`. https://bugs.python.org/issue37323
* bpo-37137: Fix test_asyncio: use TestCase.set_event_loop() (GH-13779)Victor Stinner2019-06-031-13/+8
| | | | | | | | | Replace asyncio.set_event_loop() with TestCase.set_event_loop() of test_asyncio.utils: this method calls TestCase.close_loop() which waits until the executor completes, to avoid leaking dangling threads. Inherit from test_asyncio.utils.TestCase rather than unittest.TestCase.
* bpo-36999: Add asyncio.Task.get_coro() (GH-13680)Alex Grönholm2019-05-301-0/+10
| | | https://bugs.python.org/issue36999
* bpo-32528: Make asyncio.CancelledError a BaseException. (GH-13528)Yury Selivanov2019-05-271-2/+2
| | | | | | | | | | | | | | | 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-36921: Deprecate @coroutine for sake of async def (GH-13346)Andrew Svetlov2019-05-161-221/+211
| | | | | | 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-1/+10
| | | | | | | | | | | | | | (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-0/+9
|
* asyncio: PendingDeprecationWarning -> DeprecationWarning (GH-12494)Inada Naoki2019-03-221-9/+9
| | | `Task.current_task()` and `Task.all_tasks()` will be removed in 3.9.
* bpo-35504: Fix segfaults and SystemErrors when deleting certain attrs. ↵Zackery Spytz2018-12-171-0/+9
| | | | (GH-11175)
* bpo-34890: Make iscoroutinefunction, isgeneratorfunction and ↵Pablo Galindo2018-10-261-2/+2
| | | | | | | | | | | isasyncgenfunction work with functools.partial (GH-9903) inspect.isfunction() processes both inspect.isfunction(func) and inspect.isfunction(partial(func, arg)) correctly but some other functions in the inspect module (iscoroutinefunction, isgeneratorfunction and isasyncgenfunction) lack this functionality. This commits adds a new check in the mentioned functions in the inspect module so they can work correctly with arbitrarily nested partial functions.
* bpo-34872: Fix self-cancellation in C implementation of asyncio.Task (GH-9679)Elvis Pranskevichus2018-10-031-0/+36
| | | | | | | | | | | | | | | | | The C implementation of asyncio.Task currently fails to perform the cancellation cleanup correctly in the following scenario. async def task1(): async def task2(): await task3 # task3 is never cancelled asyncio.current_task().cancel() await asyncio.create_task(task2()) The actuall error is a hardcoded call to `future_cancel()` instead of calling the `cancel()` method of a future-like object. Thanks to Vladimir Matveev for noticing the code discrepancy and to Yury Selivanov for coming up with a pathological scenario.
* bpo-34728: Fix asyncio tests to run under "-Werror" (GH-9661)Yury Selivanov2018-10-021-98/+87
|
* bpo-34728: Remove deprecate *loop* argument in asyncio.sleep (GH-9415)João Júnior2018-09-241-0/+29
| | | | | | | | | | | | | | | | * 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
* Make regular expressions in test_tasks.py raw strings. (GH-8759)Benjamin Peterson2018-08-141-2/+2
| | | | | | | | | | | Follow up to bpo-34270. Fixes: ``` Lib/test/test_asyncio/test_tasks.py:330: DeprecationWarning: invalid escape sequence \d match1 = re.match("^<Task pending name='Task-(\d+)'", repr(t1)) Lib/test/test_asyncio/test_tasks.py:332: DeprecationWarning: invalid escape sequence \d match2 = re.match("^<Task pending name='Task-(\d+)'", repr(t2)) ```
* bpo-34270: Make it possible to name asyncio tasks (GH-8547)Alex Grönholm2018-08-081-7/+48
| | | Co-authored-by: Antti Haapala <antti.haapala@anttipatterns.com>
* bpo-32676, test_asyncio: Fix warning in test_error_in_call_soon() (GH-7462)Victor Stinner2018-06-061-1/+5
| | | | | | | Fix "<CoroWrapper ...> was never yielded from" warning in PyTask_PyFuture_Tests.test_error_in_call_soon() of test_asyncio.test_tasks. Close manually the coroutine on error.
* bpo-33789, test_asyncio: Hide PendingDeprecationWarning (GH-7461)Victor Stinner2018-06-061-1/+2
| | | Hide PendingDeprecationWarning in test__register_task_3().
* bpo-33562: Check the global asyncio event loop policy isn't set after any ↵Brett Cannon2018-06-021-0/+4
| | | | tests (GH-7328)
* bpo-32684: Fix nits in tests (GH-7225)Yury Selivanov2018-05-291-3/+3
|
* bpo-32751: Wait for task cancellation in asyncio.wait_for() (GH-7216)Elvis Pranskevichus2018-05-291-0/+56
| | | | | | | | | | | | | | | | | | | | | | | 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/+28
| | | | (GH-7209)
* bpo-32610: Fix asyncio.all_tasks() to return only pending tasks. (GH-7174)Yury Selivanov2018-05-281-2/+27
|
* bpo-31787: Prevent refleaks when calling __init__() more than once (GH-3995)Oren Milman2018-02-131-0/+14
|
* bpo-32327: Revert loop.run_in_executor behaviour: return a Future. (#5392)Yury Selivanov2018-01-281-3/+2
| | | | I've run some tests on 3.7 asyncio and it appears that too many things assume that run_in_executor returns a Future.
* bpo-32636: Fix two bugs in test_asyncio (#5302)Victor Stinner2018-01-241-1/+1
|
* bpo-32636: Fix @asyncio.coroutine debug mode bug exposed by gh-5250 (#5291)Nathaniel J. Smith2018-01-241-0/+17
|
* bpo-32643: Drop support for a few private Task and Future APIs. (#5293)Yury Selivanov2018-01-241-25/+3
| | | | | | | | Specifically, it's not possible to subclass Task/Future classes and override the following methods: * Future._schedule_callbacks * Task._step * Task._wakeup
* bpo-32633: Fix some warnings in test_asyncio.test_tasks (#5280)Nathaniel J. Smith2018-01-231-2/+8
|
* bpo-32436: Implement PEP 567 (#5027)Yury Selivanov2018-01-231-10/+99
|
* bpo-31721: Allow Future._log_traceback to only be set to False (#5009)Yury Selivanov2017-12-251-0/+9
|
* bpo-32363: Disable Task.set_exception() and Task.set_result() (#4923)Yury Selivanov2017-12-251-22/+71
|
* bpo-32415: Fix "error is already set" (#4999)Yury Selivanov2017-12-231-0/+26
|
generated by cgit v0.12 at 2025-03-22 21:30:25 (GMT)