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

[Ned Batchelder]

On 5/22/14 1:16 PM, Nathaniel Smith wrote:
> 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
>

You've used the word "just" three times, glossing over the fact that we 
have no facility for marking statements as an uber instruction, and 
you've made no proposal for how it might work.  Even if we build (and 
test!) a way to do that, it only covers this particular kind of oddity 
with optimized code.

--Ned.