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

[Trip Volpe]

(First, shouldn't this be in the "disable all peephole optimizations"
thread? Raymond seems to have replied to the digest..!)

On Wed, May 21, 2014 at 2:14 PM, Nathaniel Smith <njs at pobox.com> wrote:
> Isn't the real problem here that the peephole optimizer violates the
> first rule of optimization ("don't change semantics") by breaking
> sys.settrace? Couldn't we fix this directly?

I agree with this. Adding a command line flag to tinker with code
generation may well be opening a can of worms, but "the peephole optimizer
shouldn't change semantics" is a more compelling argument, although fixing
it from that angle is obviously more involved. One problem is that
functions like settrace() expose low-level details to the higher-level
semantics. It's a fair question as to whether it should be considered
kosher to expose implementation details like the peephole optimizer through
such interfaces.

I could get behind an implementation that hides the erasure of lines that
are still (semantically) being executed, without disabling the peephole
optimizer.

- Trip

On Wed, May 21, 2014 at 2:14 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Wed, May 21, 2014 at 8:44 PM, Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:
> > * I sympathize with "there is an irritating dimple in coverage.py"
> > but that hasn't actually impaired its usability beyond creating a
> > curiosity.  Using that a reason to add a new CPython-only
> > command-line switch seems like having the tail wag the dog.
>
> I've certainly been frustrated by this wart in coverage.py's output --
> if one uses a dev cycle where you constantly review every uncovered
> line to make sure that tests are doing what you want, then even a
> small number of spurious uncovered lines that appear and disappear
> based on the optimizer's whim can result in a lot of wasted time. (Not
> to mention the hours wasted the first time I ran into this, trying to
> figure out why my tests weren't working and writing new ones
> specifically to target the optimized-out line...)
>
> That said, I'm also sympathetic to your point.
>
> Isn't the real problem here that the peephole optimizer violates the
> first rule of optimization ("don't change semantics") by breaking
> sys.settrace? Couldn't we fix this directly?
>
> One approach might be to enhance co_lnotab (if anyone dares touch it)
> so that it can record that a peepholed jump instruction logically
> belongs to multiple *different* lines, and when we encounter such an
> instruction we call the trace function multiple times. Then the
> peephole optimizer just has to propagate line number information
> whenever it short-circuits a jump.
>
> Or perhaps it would be enough to add a dead-code optimization pass
> after the peephole optimizer, so that coverage.py can at least see
> that things like Ned's "continue" didn't actually generate any code.
> (This is suboptimal as well, since it will still cause coverage.py to
> produce somewhat confusing output, as if the "continue" line had a
> comment instead of real code -- but it'd still be better than the
> status quo.)
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140521/ad30465c/attachment.html>