A CodeString looks rather like a list. It sprouts all the
list-emulation methods __getitem__, __len__,
__delslice__, index, etc, along with some extra
The main point of the class is to keep jumps under control. You can
add or remove opcodes as you like and jumps that aren't directly
involved are unaffected. What happens to jumps that target affected
opcodes is detailed in the method descriptions below.
- CodeString ([cs])
Initialize the codestring with code from cs, if
supplied. Otherwise create an empty codestring. cs can be any
code-y object, i.e. a codestring, code object, function or method.
- disassemble (codestring)
I'm not sure this function is well named or necessary. Nevertheless,
it initializes the CodeString from codestring, splitting
it into bytecodes, creating the opcode objects and resolving jumps.
- add_label (label)
Add label to the CodeString's list of labels.
- find_labels (index)
Return a list of labels that point to the indexth opcode.
- assembles ()
Return a string that represents the CodeString's present
The list methods all do what you would expect them to; the
descriptions only mention what happens to labels that point at
- __getitem__ (index)
- __setitem__ (index,value)
Labels pointing to the replaced opcode are directed at the freshly
- __delitem__ (index)
Labels targeting the deleted item are directed to the following
opcode, unless it's the last, in which case they are directed to what
has become the last opcode.
- __getslice__ (lo,hi)
- __setslice__ (lo,hi,values)
Labels pointing into the block being stomped on are redirected to the
start of the block being inserted. If there are labels pointing
into the block being stomped on, rather than at it's start, a
warning is printed, because that is a bit dodgy.
- __delslice__ (lo,hi)
Labels that point into the block being stomped on get attached to what
immediately follows the block, unless the end is being deleted, then
they are attached to what is now the last opcode.
- __len__ ()
- append (value)
- extend (list)
- remove (x)
Behaves like __delitem__, i.e. labels targeting the deleted
item are directed to the following opcode, unless it's the last, in
which case they are directed to what has become the last opcode.
- index (x)
As mentioned in the overview, funky acquisition stuff means that
opcodes you think should actually be the same object may well not
be. However opcodes define a __cmp__ method that performs
logical is style matching, so the method behaves how you
would expect it to.
The list of opcodes. Probably best not to access this directly.
A dictionary mapping byte offsets into indices into the
opcodes list. Only valid from construction until the first
mutation of the code string, so again probably best left alone.
A list of labels that point to bits of the codestring.
The EditableCode that the code is part of.
Send comments to firstname.lastname@example.org