Somewhat inevitably, the detailed disassembler tests broke when Antoine updated the code generation for function definitions (as part of PEP 3155). (At least, the tests broke, and PEP 3155 seems the most likely culprit).

I subsequently realised there's a potential opportunity here: if Instruction objects define an __eq__ method instead of relying on the custom "assertBytecodeExactlyMatches" helper method the new disassembly tests currently use, then the sequence diffing functionality in unittest could be very helpful in identifying and fixing discrepancies between actual output and expected output.

However, the assertBytecodeExactlyMatches() API has this concept of a "line_offset" which it uses to cope with some of the introspection fodder moving around in the files, so the question then becomes how to deal with that in the context of an __eq__ implementation.

Accordingly, my current plan is to offer "line_offset" as a keyword-only argument to get_instructions() itself. That way, the entire sequence of generated bytecode can easily be adjusted to (for example), be based around the first line being line 1, even if the actual code object being disassembled is located elsewhere in the original source file.