Overview

Request 479281 accepted

- update for singlespec
- update to 4.3.4:
- Using the --skip-covered option on an HTML report with 100% coverage would
cause a “No data to report” error, as reported in issue 549. This is now
fixed; thanks, Loïc Dachary.
- If-statements can be optimized away during compilation, for example, if 0:
or if __debug__:. Coverage.py had problems properly understanding these
statements which existed in the source, but not in the compiled bytecode.
This problem, reported in issue 522, is now fixed.
- If you specified --source as a directory, then coverage.py would look for
importable Python files in that directory, and could identify ones that had
never been executed at all. But if you specified it as a package name, that
detection wasn’t performed. Now it is, closing issue 426. Thanks to Loïc
Dachary for the fix.
- If you started and stopped coverage measurement thousands of times in your
process, you could crash Python with a “Fatal Python error: deallocating
None” error. This is now fixed. Thanks to Alex Groce for the bug report.
- On PyPy, measuring coverage in subprocesses could produce a warning: “Trace
function changed, measurement is likely wrong: None”. This was spurious,
and has been suppressed.
- Previously, coverage.py couldn’t start on Jython, due to that
implementation missing the multiprocessing module (issue 551). This problem
has now been fixed. Also, issue 322 about not being able to invoke coverage
conveniently, seems much better: jython -m coverage run myprog.py works
properly.
- Let’s say you ran the HTML report over and over again in the same output
directory, with --skip-covered. And imagine due to your heroic test-writing
efforts, a file just acheived the goal of 100% coverage. With coverage.py
4.3, the old HTML file with the less-than-100% coverage would be left
behind. This file is now properly deleted.

Request History
Jan Matejek's avatar

matejcik created request

- update for singlespec
- update to 4.3.4:
- Using the --skip-covered option on an HTML report with 100% coverage would
cause a “No data to report” error, as reported in issue 549. This is now
fixed; thanks, Loïc Dachary.
- If-statements can be optimized away during compilation, for example, if 0:
or if __debug__:. Coverage.py had problems properly understanding these
statements which existed in the source, but not in the compiled bytecode.
This problem, reported in issue 522, is now fixed.
- If you specified --source as a directory, then coverage.py would look for
importable Python files in that directory, and could identify ones that had
never been executed at all. But if you specified it as a package name, that
detection wasn’t performed. Now it is, closing issue 426. Thanks to Loïc
Dachary for the fix.
- If you started and stopped coverage measurement thousands of times in your
process, you could crash Python with a “Fatal Python error: deallocating
None” error. This is now fixed. Thanks to Alex Groce for the bug report.
- On PyPy, measuring coverage in subprocesses could produce a warning: “Trace
function changed, measurement is likely wrong: None”. This was spurious,
and has been suppressed.
- Previously, coverage.py couldn’t start on Jython, due to that
implementation missing the multiprocessing module (issue 551). This problem
has now been fixed. Also, issue 322 about not being able to invoke coverage
conveniently, seems much better: jython -m coverage run myprog.py works
properly.
- Let’s say you ran the HTML report over and over again in the same output
directory, with --skip-covered. And imagine due to your heroic test-writing
efforts, a file just acheived the goal of 100% coverage. With coverage.py
4.3, the old HTML file with the less-than-100% coverage would be left
behind. This file is now properly deleted.


Jan Matejek's avatar

matejcik accepted request

ok

openSUSE Build Service is sponsored by