Nick Coghlan added the comment:
Hmm, looking at dis.py, 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:
@property
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19722>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
