I recently wasplaying with bytecode instructions and found that thedis.Instruction didalmost what I needed, but not quite -- I ended up reimplementing it, mostly reinventing the wheel. I propose to improve this class in dis.py as follows:

• start_offset: start of the instructionincludingEXTENDED_ARG prefixes
• jump_target: bytecode offset where a jump goes (can be property computed fromopcode andarg)
• baseopname,baseopcode: name and opcode of the "family head" for specialized instructions (can be properties)
• cache_offset,end_offset: start and end of the cache entries (can be properties)
• oparg: alias forarg (in most places we seem to useoparg)

Of these, onlystart_offset needs to be a new data field -- the others can be computed properties. For my application,start_offset was important to have (though admittedly I could have done without if I had treatedEXTENDED_ARG as aNOP). It just feels wrong thatoffset points to the opcode butoparg includes the extended arg -- this means one has to explicitly representEXTENDED_ARG instructions in a sequence of instructions even though theireffect (arg) is included in theInstruction.

I also added a__str__ method to myInstruction class that shows the entire instruction -- this could call the_disassemble method with default arguments. Here I made one improvement over_disassemble: if the opname is longer than_OPNAME_WIDTH but the arg is shorter than_OPARG_WIDTH, I let the opname overflow into the space reserved for the oparg, leaving at least one space in between. This makes for fewer misaligned opargs, since the opname is left-justified and the oparg is right-justified.

@isidentical@serhiy-storchaka@iritkatriel@markshannon@brandtbucher

Linked PRs

• gh-102676: Add more convenience properties todis.Instruction #103969