summaryrefslogtreecommitdiffstatshomepage
path: root/tests/basics/async_for.py
Commit message (Collapse)AuthorAge
* py/compile: Fix async for's stack handling of iterator expression.Damien George2023-07-13
| | | | | | | | | | | | | Prior to this fix, async for assumed the iterator expression was a simple identifier, and used that identifier as a local to store the intermediate iterator object. This is incorrect behaviour. This commit fixes the issue by keeping the iterator object on the stack as an anonymous local variable. Fixes issue #11511. Signed-off-by: Damien George <damien@micropython.org>
* py/compile: Don't await __aiter__ special method in async-for.Jonathan Hogg2020-07-25
| | | | | | | | | | | | | | | | | | | | MicroPython's original implementation of __aiter__ was correct for an earlier (provisional) version of PEP492 (CPython 3.5), where __aiter__ was an async-def function. But that changed in the final version of PEP492 (in CPython 3.5.2) where the function was changed to a normal one. See https://www.python.org/dev/peps/pep-0492/#why-aiter-does-not-return-an-awaitable See also the note at the end of this subsection in the docs: https://docs.python.org/3.5/reference/datamodel.html#asynchronous-iterators And for completeness the BPO: https://bugs.python.org/issue27243 To be consistent with the Python spec as it stands today (and now that PEP492 is final) this commit changes MicroPython's behaviour to match CPython: __aiter__ should return an async-iterable object, but is not itself awaitable. The relevant tests are updated to match. See #6267.
* tests: Add 6 tests for async await/for/with.Damien George2016-04-13