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.
This commit is contained in:
committed by
Damien George
parent
fe7d47971f
commit
37e1b5c891
@@ -1798,7 +1798,8 @@ STATIC void compile_async_for_stmt(compiler_t *comp, mp_parse_node_struct_t *pns
|
||||
uint try_finally_label = comp_next_label(comp);
|
||||
|
||||
compile_node(comp, pns->nodes[1]); // iterator
|
||||
compile_await_object_method(comp, MP_QSTR___aiter__);
|
||||
EMIT_ARG(load_method, MP_QSTR___aiter__, false);
|
||||
EMIT_ARG(call_method, 0, 0, 0);
|
||||
compile_store_id(comp, context);
|
||||
|
||||
START_BREAK_CONTINUE_BLOCK
|
||||
|
||||
Reference in New Issue
Block a user