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

Nathaniel Smith njs at pobox.com
Thu May 22 01:09:51 CEST 2014


On Wed, May 21, 2014 at 11:50 PM, Greg Ewing
<greg.ewing at 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


More information about the Python-ideas mailing list