On Wed, May 21, 2014 at 11:50 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Raymond Hettinger wrote:
* I sympathize with "there is an irritating dimple in coverage.py" but that hasn't actually impaired its usability beyond creating a curiosity.
Another way to address this would be to make coverage.py smart enough to understand when a source line has been optimised away and always report it as executed.
AFAICT the only ways to make coverage.py "smart enough" would be: 1) Teach coverage.py to perform a full (sound) reachability analysis on bytecode. 2) Teach coverage.py to notice when a jump instruction doesn't go where you might expect it to based on a naive reading of the source code, and then reverse-engineer from this what sequence of jump instructions that must have been merged to produce the one we observe. I guess in practice this probably would require carrying around a patched copy of the full compiler code from every Python release. The problem here is that the Python compiler is throwing away information that only it has. Asking coverage.py to reconstruct that without help from the compiler isn't reasonable IMO. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org