diff options
| author | Jonathan Hogg <me@jonathanhogg.com> | 2020-07-21 18:47:28 +0100 |
|---|---|---|
| committer | Kenny <3454741+WarriorOfWire@users.noreply.github.com> | 2020-07-24 22:55:37 -0700 |
| commit | 901f3dce6e5e7c1501550ca0b7f3283848194a2e (patch) | |
| tree | c2a1b03cd7f6b77dc6e4fad9e7297c9ab16c2796 /py/persistentcode.h | |
| parent | a6e048686fe6999c4231582b7d9e69a7dc679257 (diff) | |
py/compile: Don't await __aiter__ special method in async-for.
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.
Diffstat (limited to 'py/persistentcode.h')
0 files changed, 0 insertions, 0 deletions