The restriction that line numbers must be monotonically increasing w.r.t bytecode offset in the co_lnotab array prevents a number of beneficial transformations in the bytecode compiler.

This patch allows negative line number deltas and uses this capability to generate code for 'while' loops in standard text book fashion, putting the test *after* the body.

How does this interact with pdb?

The interaction between bdb/pdb and the line number table is via the frame.f_lineno attribute.

Allowing signed offsets changes the one-to-one line muber => bytecode offset relation into a one-to-many relation.

Reading frame.f_lineno is not an issue as each bytecode offset will always refer to exactly one line number.

Setting frame.f_lineno requires some thought as each line number could potentially refer to several bytecode offsets. However, the proposed patch retains the one-to-one relation, as the test in the while statement is merely moved, not duplicated.

I am reluctant to change frame_setlineno() until there really is a one-to-many relation as it will be untestable.
Once a one-to-many relation exists (e.g. duplicating finally blocks to avoid 'pseudo excpetions') then frame_setlineno should be modified (and tests added)

> How does this interact with pdb?

Also, the findlinestarts() function from the dis module computes line
numbers from lnotab. This function is used by pdb when displaying the
lines of a traceback.

Your patch doesn't seem to work properly: a "while" loop doesn't generate negative line offsets. The reason seems to be that compiler_set_lineno() prevents it.
(also, if I re-add the `assert(d_lineno >= 0);` in assemble_lnotab(), I don't get any crash)

Good news: this issue has been fixed in issue #26107.