[Python-ideas] Python-ideas Digest, Vol 90, Issue 30

[Nathaniel Smith]

On Thu, May 22, 2014 at 4:32 PM, Ned Batchelder <ned at nedbatchelder.com> wrote:
> On 5/22/14 9:49 AM, Skip Montanaro wrote:
>> It seems to me that Ned has revealed a bug in the peephole optimizer.
>> It zapped an entire source line's worth of bytecode, but failed to
>> delete the relevant entry in the line number table of the resulting
>> code object. If I had my druthers, that would be the change I'd
>> prefer.
>
> I think it is the nature of optimization that it will destroy useful
> information.  I don't think it will always be possible to retain enough
> back-mapping that the optimized code can be understood as if it had not been
> optimized.   For example, the debug issue would still be present: if you run
> pdb and set a breakpoint on the "continue" line, it will never be hit.  Even
> if the optimizer cleaned up after itself perfectly (in fact, especially so),
> that breakpoint will still not be hit.  You simply cannot reason about
> optimized code without having to mentally understand the transformations
> that have been applied.

In this particular case, the back-mapping problem is pretty minor.
IIUC the optimization is that if we have (abusing BASIC notation)

10 GOTO 20
20 GOTO 30
30 ...

then in fact the operations at lines 10 and 20 are, from the point of
view of the rest of the program, indivisible -- every time you execute
10 you also execute 20, there is no way to tell from outside whether
we paused in betwen executing 10 and 20, etc. Effectively we just have
a single uber-instruction that does both:

(10, 20) GOTO 30
30 ...

So from the coverage point of view, just marking line 20 as covered
every time line 10 is executed is the Right Thing To Do. From the
debugging point of view, a breakpoint set at line 20 should just trip
whenever line 10 is executed -- it's not like there's any way to tell
whether we're "half way through" the jump sequence or not. It's a
pretty solid abstraction.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org