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 ncoghlan
Recipients brett.cannon, eric.snow, larry, ncoghlan
Date 2013-11-23.00:37:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hmm, looking at, I'm -1 on exposing this as a public opcode module API at this point, although I'm still a fan of exposing it as opcode._stack_effect to allow advanced users access (ala sys._get_frames).

I initially thought the required addition to dis.Instruction would just be:

    def stack_effect(self):
        return opcode.stack_effect(self.opcode, self.arg)

However, that doesn't necessarily work, since self.arg may be None.

That means stack_effect has to be at least:

    def stack_effect(opcode, oparg=None):
        if oparg is None:
            if opcode >= HAVE_ARGUMENT:
                raise ValueError("This opcode needs an argument")
            oparg = 0
        return _opcode.stack_effect(opcode, oparg)

However, even that's not quite accurate, since if the previous opcode was EXTENDED_ARG, you should be adding *that* arg times 65536 to oparg in order to figure out the stack effect.

It's that need to take the previous opcode into account to correctly determine the value for "oparg" that makes this a bit tricky.

Although, I guess the latter concern would only apply to integration into the dis module - for the opcode module, it just needs to be documented that the calculation of the passed in oparg value should take EXTENDED_ARG into account.
Date User Action Args
2013-11-23 00:37:59ncoghlansetrecipients: + ncoghlan, brett.cannon, larry, eric.snow
2013-11-23 00:37:59ncoghlansetmessageid: <>
2013-11-23 00:37:59ncoghlanlinkissue19722 messages
2013-11-23 00:37:58ncoghlancreate