coverage-3.6b2

• Coverage.py runs on Python 2.3 and 2.4 again. It was broken in 3.6b1.
• The C extension is optionally compiled using a different more widely-used technique, taking another stab at fixing issue 80 once and for all.
• Combining data files would create entries for phantom files if used with source and path aliases. It no longer does.
• debug sys now shows the configuration file path that was read.
• If an oddly-behaved package claims that code came from an empty-string file name, coverage.py no longer associates it with the directory name, fixing issue 221.

coverage-3.6b1

• Wildcards in include= and omit= arguments were not handled properly in reporting functions, though they were when running. Now they are handled uniformly, closing issue 143 and issue 163. NOTE: it is possible that your configurations may now be incorrect. If you use include or omit during reporting, whether on the command line, through the API, or in a configuration file, please check carefully that you were not relying on the old broken behavior.
• The report, html, and xml commands now accept a --fail-under switch that indicates in the exit status whether the coverage percentage was less than a particular value. Closes issue 139.
• The reporting functions coverage.report(), coverage.html_report(), and coverage.xml_report() now all return a float, the total percentage covered measurement.
• The HTML report’s title can now be set in the configuration file, with the --title switch on the command line, or via the API.
• Configuration files now support substitution of environment variables, using syntax like ${WORD}. Closes issue 97.
• Embarrassingly, the [xml] output= setting in the .coveragerc file simply didn’t work. Now it does.
• The XML report now consistently uses file names for the file name attribute, rather than sometimes using module names. Fixes issue 67. Thanks, Marcus Cobden.
• Coverage percentage metrics are now computed slightly differently under branch coverage. This means that completely unexecuted files will now correctly have 0% coverage, fixing issue 156. This also means that your total coverage numbers will generally now be lower if you are measuring branch coverage.
• When installing, now in addition to creating a “coverage” command, two new aliases are also installed. A “coverage2” or “coverage3” command will be created, depending on whether you are installing in Python 2.x or 3.x. A “coverage-X.Y” command will also be created corresponding to your specific version of Python. Closes issue 111.
• The coverage.py installer no longer tries to bootstrap setuptools or Distribute. You must have one of them installed first, as issue 202 recommended.
• The coverage.py kit now includes docs (closing issue 137) and tests.
• On Windows, files are now reported in their correct case, fixing issue 89 and issue 203.
• If a file is missing during reporting, the path shown in the error message is now correct, rather than an incorrect path in the current directory. Fixes issue 60.
• Running an HTML report in Python 3 in the same directory as an old Python 2 HTML report would fail with a UnicodeDecodeError. This issue (issue 193) is now fixed.
• Fixed yet another error trying to parse non-Python files as Python, this time an IndentationError, closing issue 82 for the fourth time…
• If coverage xml fails because there is no data to report, it used to create a zero-length XML file. Now it doesn’t, fixing issue 210.
• Jython files now work with the --source option, fixing issue 100.
• Running coverage.py under a debugger is unlikely to work, but it shouldn’t fail with “TypeError: ‘NoneType’ object is not iterable”. Fixes issue 201.
• On some Linux distributions, when installed with the OS package manager, coverage.py would report its own code as part of the results. Now it won’t, fixing issue 214, though this will take some time to be repackaged by the operating systems.
• Docstrings for the legacy singleton methods are more helpful. Thanks Marius Gedminas. Closes issue 205.
• The pydoc tool can now show documentation for the class coverage.coverage. Closes issue 206.
• Added a page to the docs about contributing to coverage.py, closing issue 171.
• When coverage.py ended unsuccessfully, it may have reported odd errors like 'NoneType' object has no attribute 'isabs'. It no longer does, so kiss issue 153 goodbye.

coverage-3.5.3

• Line numbers in the HTML report line up better with the source lines, fixing issue 197, thanks Marius Gedminas.
• When specifying a directory as the source= option, the directory itself no longer needs to have a __init__.py file, though its sub-directories do, to be considered as source files.
• Files encoded as UTF-8 with a BOM are now properly handled, fixing issue 179. Thanks, Pablo Carballo.
• Fixed more cases of non-Python files being reported as Python source, and then not being able to parse them as Python. Closes issue 82 (again). Thanks, Julian Berman.
• Fixed memory leaks under Python 3, thanks, Brett Cannon. Closes issue 147.
• Optimized .pyo files may not have been handled correctly, issue 195. Thanks, Marius Gedminas.
• Certain unusually named file paths could have been mangled during reporting, issue 194. Thanks, Marius Gedminas.
• Try to do a better job of the impossible task of detecting when we can’t build the C extension, fixing issue 183.
• Testing is now done with tox, thanks, Marc Abramowitz.

coverage-3.5.2

No changes since 3.5.2.b1

coverage-3.5.2b1

• The HTML report has slightly tweaked controls: the buttons at the top of the page are color-coded to the source lines they affect.
• Custom CSS can be applied to the HTML report by specifying a CSS file as the extra_css configuration value in the [html] section.
• Source files with custom encodings declared in a comment at the top are now properly handled during reporting on Python 2. Python 3 always handled them properly. This fixes issue 157.
• Backup files left behind by editors are no longer collected by the source= option, fixing issue 168.
• If a file doesn’t parse properly as Python, we don’t report it as an error if the file name seems like maybe it wasn’t meant to be Python. This is a pragmatic fix for issue 82.
• The -m switch on coverage report, which includes missing line numbers in the summary report, can now be specified as show_missing in the config file. Closes issue 173.
• When running a module with coverage run -m <modulename>, certain details of the execution environment weren’t the same as for python -m <modulename>. This had the unfortunate side-effect of making coverage run -m unittest discover not work if you had tests in a directory named “test”. This fixes issue 155 and issue 142.
• Now the exit status of your product code is properly used as the process status when running python -m coverage run .... Thanks, JT Olds.
• When installing into pypy, we no longer attempt (and fail) to compile the C tracer function, closing issue 166.

coverage-3.5.1

• The [paths] feature unfortunately didn’t work in real world situations where you wanted to, you know, report on the combined data. Now all paths stored in the combined file are canonicalized properly.

coverage-3.5.1b1

• When combining data files from parallel runs, you can now instruct coverage.py about which directories are equivalent on different machines. A [paths] section in the configuration file lists paths that are to be considered equivalent. Finishes issue 17.
• for-else constructs are understood better, and don’t cause erroneous partial branch warnings. Fixes issue 122.
• Branch coverage for with statements is improved, fixing issue 128.
• The number of partial branches reported on the HTML summary page was different than the number reported on the individual file pages. This is now fixed.
• An explicit include directive to measure files in the Python installation wouldn’t work because of the standard library exclusion. Now the include directive takes precedence, and the files will be measured. Fixes issue 138.
• The HTML report now handles Unicode characters in Python source files properly. This fixes issue 124 and issue 144. Thanks, Devin Jeanpierre.
• In order to help the core developers measure the test coverage of the standard library, Brandon Rhodes devised an aggressive hack to trick Python into running some coverage.py code before anything else in the process. See the coverage/fullcoverage directory if you are interested.

coverage-3.5

• The HTML report hotkeys now behave slightly differently when the current chunk isn’t visible at all: a chunk on the screen will be selected, instead of the old behavior of jumping to the literal next chunk. The hotkeys now work in Google Chrome. Thanks, Guido van Rossum.

coverage-3.5b1

• The HTML report now has hotkeys. Try n, s, m, x, b, p, and c on the overview page to change the column sorting. On a file page, r, m, x, and p toggle the run, missing, excluded, and partial line markings. You can navigate the highlighted sections of code by using the j and k keys for next and previous. The 1 (one) key jumps to the first highlighted section in the file, and 0 (zero) scrolls to the top of the file.
• The --omit and --include switches now interpret their values more usefully. If the value starts with a wildcard character, it is used as-is. If it does not, it is interpreted relative to the current directory. Closes issue 121.
• Partial branch warnings can now be pragma’d away. The configuration option partial_branches is a list of regular expressions. Lines matching any of those expressions will never be marked as a partial branch. In addition, there’s a built-in list of regular expressions marking statements which should never be marked as partial. This list includes while True:, while 1:, if 1:, and if 0:.
• The coverage() constructor accepts single strings for the omit= and include= arguments, adapting to a common error in programmatic use.
• Modules can now be run directly using coverage run -m modulename, to mirror Python’s -m flag. Closes issue 95, thanks, Brandon Rhodes.
• coverage run didn’t emulate Python accurately in one small detail: the current directory inserted into sys.path was relative rather than absolute. This is now fixed.
• HTML reporting is now incremental: a record is kept of the data that produced the HTML reports, and only files whose data has changed will be generated. This should make most HTML reporting faster.
• Pathological code execution could disable the trace function behind our backs, leading to incorrect code measurement. Now if this happens, coverage.py will issue a warning, at least alerting you to the problem. Closes issue 93. Thanks to Marius Gedminas for the idea.
• The C-based trace function now behaves properly when saved and restored with sys.gettrace() and sys.settrace(). This fixes issue 125 and issue 123. Thanks, Devin Jeanpierre.
• Source files are now opened with Python 3.2’s tokenize.open() where possible, to get the best handling of Python source files with encodings. Closes issue 107, thanks, Brett Cannon.
• Syntax errors in supposed Python files can now be ignored during reporting with the -i switch just like other source errors. Closes issue 115.
• Installation from source now succeeds on machines without a C compiler, closing issue 80.
• Coverage.py can now be run directly from a working tree by specifying the directory name to python: python coverage_py_working_dir run .... Thanks, Brett Cannon.
• A little bit of Jython support: coverage run can now measure Jython execution by adapting when $py.class files are traced. Thanks, Adi Roiban. Jython still doesn’t provide the Python libraries needed to make coverage reporting work, unfortunately.
• Internally, files are now closed explicitly, fixing issue 104. Thanks, Brett Cannon.

coverage-3.4

• The XML report is now sorted by package name, fixing issue 88.
• Programs that exited with sys.exit() with no argument weren’t handled properly, producing a coverage.py stack trace. That is now fixed.