This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Jim.Jewett
Recipients Jim.Jewett, yselivanov
Date 2016-02-04.21:07:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1454620080.04.0.670513123841.issue26286@psf.upfronthosting.co.za>
In-reply-to
Content
https://docs.python.org/3/library/dis.html includes a section describing the various opcodes.

Current documentation: """
Coroutine opcodes

GET_AWAITABLE
Implements TOS = get_awaitable(TOS), where get_awaitable(o) returns o if o is a coroutine object or a generator object with the CO_ITERABLE_COROUTINE flag, or resolves o.__await__.

GET_AITER
Implements TOS = get_awaitable(TOS.__aiter__()). See GET_AWAITABLE for details about get_awaitable

GET_ANEXT
Implements PUSH(get_awaitable(TOS.__anext__())). See GET_AWAITABLE for details about get_awaitable

BEFORE_ASYNC_WITH
Resolves __aenter__ and __aexit__ from the object on top of the stack. Pushes __aexit__ and result of __aenter__() to the stack.

SETUP_ASYNC_WITH
Creates a new frame object.
"""

(1)  There is a PUSH macro in ceval.c, but no PUSH bytecode.  I spent a few minutes trying to figure out what a PUSH command was, and how the GET_ANEXT differed from 
    TOS = get_awaitable(TOS.__anext__())
which would match the bytecodes right above it.

After looking at ceval.c, I think GET_ANEXT is the only such bytecode to leave the original TOS in place, but I'm not certain about that.  Please be explicit.  (Unless they are the same, in which case, please use the same wording.)
 
(2)  The coroutine bytecode instructions should have a "New in 3.5" marker, as the GET_YIELD_FROM_ITER does.  It might make sense to just place the mark under Coroutine opcodes section header and say it applies to all of them, instead of marking each individual opcode.  

(3)  The GET_AITER and GET_ANEXT descriptions do not show the final period.  Opcodes such as INPLACE_LSHIFT also end with a code quote, but still include a (not-marked-as-code) final period.

(4)  Why does SETUP_ASYNC_WITH talk about frames?  Is there actually a python frame involved, or is this another bytecode "block", similar to that used for except and finally?
History
Date User Action Args
2016-02-04 21:08:00Jim.Jewettsetrecipients: + Jim.Jewett, yselivanov
2016-02-04 21:08:00Jim.Jewettsetmessageid: <1454620080.04.0.670513123841.issue26286@psf.upfronthosting.co.za>
2016-02-04 21:07:59Jim.Jewettlinkissue26286 messages
2016-02-04 21:07:59Jim.Jewettcreate