Refer to the project consistenly as coverage.py. #275

12 files changed, 88 insertions, 90 deletions

diff --git a/doc/api.rst b/doc/api.rst
index 684bc2d..bb039e9 100644
--- a/doc/api.rst
+++ b/doc/api.rst
@@ -49,8 +49,8 @@ The CoverageData class
     :special-members: __init__
 
 
-Starting coverage automatically
--------------------------------
+Starting coverage.py automatically
+----------------------------------
 
 This function is used to start coverage measurement automatically when Python
 starts.  See :ref:`subprocess` for details.
diff --git a/doc/branch.rst b/doc/branch.rst
index 2738447..71367de 100644
--- a/doc/branch.rst
+++ b/doc/branch.rst
@@ -13,7 +13,7 @@ Branch coverage measurement
    :linenothreshold: 5
 
 
-In addition to the usual statement coverage, Coverage.py also supports branch
+In addition to the usual statement coverage, coverage.py also supports branch
 coverage measurement. Where a line in your program could jump to more than one
 next line, coverage.py tracks which of those destinations are actually visited,
 and flags lines that haven't visited all of their possible destinations.
diff --git a/doc/changes.rst b/doc/changes.rst
index e5aa67a..53ea360 100644
--- a/doc/changes.rst
+++ b/doc/changes.rst
@@ -51,7 +51,7 @@ Backward incompatibilities:
 - The ``COVERAGE_OPTIONS`` environment variable is no longer supported.  It was
   a hack for ``--timid`` before configuration files were available.
 
-- The original module-level function interface to coverage is no longer
+- The original module-level function interface to coverage.py is no longer
   supported.  You must now create a ``coverage.Coverage`` object, and use
   methods on it.
 
@@ -126,7 +126,7 @@ Improvements:
   fixed.
 
 - A new warning is possible, if a desired file isn't measured because it was
-  imported before coverage was started (`issue 353`_).
+  imported before coverage.py was started (`issue 353`_).
 
 - The `coverage.process_startup` function now will start coverage measurement
   only once, no matter how many times it is called.  This fixes problems due
@@ -137,8 +137,8 @@ API changes:
 - The class defined in the coverage module is now called ``Coverage`` instead
   of ``coverage``, though the old name still works, for backward compatibility.
 
-- You can now programmatically adjust the configuration of coverage by setting
-  items on `Coverage.config` after construction.
+- You can now programmatically adjust the configuration of coverage.py by
+  setting items on `Coverage.config` after construction.
 
 - If the `config_file` argument to the Coverage constructor is specified as
   ".coveragerc", it is treated as if it were True.  This means setup.cfg is
@@ -229,9 +229,9 @@ Version 3.7 --- 6 October 2013
 - Running code with ``coverage run -m`` now behaves more like Python does,
   setting sys.path properly, which fixes `issue 207`_ and `issue 242`_.
 
-- Coverage can now run .pyc files directly, closing `issue 264`_.
+- Coverage.py can now run .pyc files directly, closing `issue 264`_.
 
-- Coverage properly supports .pyw files, fixing `issue 261`_.
+- Coverage.py properly supports .pyw files, fixing `issue 261`_.
 
 - Omitting files within a tree specified with the ``source`` option would
   cause them to be incorrectly marked as unexecuted, as described in
@@ -247,9 +247,10 @@ Version 3.7 --- 6 October 2013
 - Trying to create an XML report with no files to report on, would cause a
   ZeroDivideError, but no longer does, fixing `issue 250`_.
 
-- When running a threaded program under the Python tracer, coverage no longer
-  issues a spurious warning about the trace function changing: "Trace function
-  changed, measurement is likely wrong: None."  This fixes `issue 164`_.
+- When running a threaded program under the Python tracer, coverage.py no
+  longer issues a spurious warning about the trace function changing: "Trace
+  function changed, measurement is likely wrong: None."  This fixes
+  `issue 164`_.
 
 - Static files necessary for HTML reports are found in system-installed places,
   to ease OS-level packaging of coverage.py.  Closes `issue 259`_.
@@ -377,8 +378,9 @@ Fixes:
 
 - Jython files now work with the ``--source`` option, fixing `issue 100`_.
 
-- Running coverage under a debugger is unlikely to work, but it shouldn't fail
-  with "TypeError: 'NoneType' object is not iterable".  Fixes `issue 201`_.
+- 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,
@@ -500,10 +502,10 @@ Version 3.5.2 --- 4 May 2012
 Version 3.5.1 --- 23 September 2011
 -----------------------------------
 
-- When combining data files from parallel runs, you can now instruct coverage
-  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`_.
+- 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`_.
@@ -525,7 +527,7 @@ Version 3.5.1 --- 23 September 2011
 
 - 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 code before anything else in the process.
+  into running some coverage.py code before anything else in the process.
   See the coverage/fullcoverage directory if you are interested.
 
 .. _issue 17: http://bitbucket.org/ned/coveragepy/issue/17/support-combining-coverage-data-from
@@ -682,7 +684,7 @@ Execution and measurement:
 - When measuring code running in a virtualenv, most of the system library was
   being measured when it shouldn't have been.  This is now fixed.
 
-- Coverage can now be run as a module: ``python -m coverage``.  Thanks,
+- Coverage.py can now be run as a module: ``python -m coverage``.  Thanks,
   Brett Cannon.
 
 .. _issue 1:  http://bitbucket.org/ned/coveragepy/issue/1/empty-__init__py-files-are-reported-as-1-executable
@@ -760,7 +762,7 @@ Version 3.2 --- 5 December 2009
 
 - Added a ``--version`` option on the command line.
 
-- Program execution under coverage is a few percent faster.
+- Program execution under coverage.py is a few percent faster.
 
 - Some exceptions reported by the command line interface have been cleaned up
   so that tracebacks inside coverage.py aren't shown.  Fixes `issue 23`_.
@@ -821,7 +823,7 @@ Version 3.0.1 --- 7 July 2009
   raised.  This is now fixed.
 
 - The coverage.py code itself will now not be measured by coverage.py, and no
-  coverage modules will be mentioned in the nose ``--with-cover`` plugin.
+  coverage.py modules will be mentioned in the nose ``--with-cover`` plugin.
 
 - When running source files, coverage.py now opens them in universal newline
   mode just like Python does.  This lets it run Windows files on Mac, for
@@ -831,13 +833,13 @@ Version 3.0.1 --- 7 July 2009
 Version 3.0 --- 13 June 2009
 ----------------------------
 
-- Coverage is now a package rather than a module.  Functionality has been split
-  into classes.
+- Coverage.py is now a package rather than a module.  Functionality has been
+  split into classes.
 
 - HTML reports and annotation of source files: use the new ``-b`` (browser)
   switch.  Thanks to George Song for code, inspiration and guidance.
 
-- The trace function is implemented in C for speed.  Coverage runs are now
+- The trace function is implemented in C for speed.  Coverage.py runs are now
   much faster.  Thanks to David Christian for productive micro-sprints and
   other encouragement.
 
diff --git a/doc/cmd.rst b/doc/cmd.rst
index b1eeb63..b7e00e5 100644
--- a/doc/cmd.rst
+++ b/doc/cmd.rst
@@ -1,8 +1,8 @@
 .. _cmd:
 
-===========================
-Coverage command line usage
-===========================
+==============================
+Coverage.py command line usage
+==============================
 
 .. :history: 20090524T134300, brand new docs.
 .. :history: 20090613T164000, final touches for 3.0
@@ -29,7 +29,7 @@ and a ``coverage-X.Y`` alias, depending on the version of Python you're using.
 For example, when installing on Python 2.7, you will be able to use
 ``coverage``, ``coverage2``, or ``coverage-2.7`` on the command line.
 
-Coverage has a number of commands which determine the action performed:
+Coverage.py has a number of commands which determine the action performed:
 
 * **run** -- Run a Python program and collect execution data.
 
@@ -96,9 +96,9 @@ but before the program invocation::
     $ coverage run --source=dir1,dir2 my_program.py arg1 arg2
     $ coverage run --source=dir1,dir2 -m packagename.modulename arg1 arg2
 
-Coverage can measure multi-threaded programs by default. If you are using
+Coverage.py can measure multi-threaded programs by default. If you are using
 more exotic concurrency, with the `greenlet`_, `eventlet`_, or `gevent`_
-libraries, then coverage will get very confused.  Use the ``--concurrency``
+libraries, then coverage.py will get very confused.  Use the ``--concurrency``
 switch to properly measure programs using these libraries.  Give it a value of
 ``greenlet``, ``eventlet``, or ``gevent``.
 
@@ -106,12 +106,12 @@ switch to properly measure programs using these libraries.  Give it a value of
 .. _gevent: http://www.gevent.org/
 .. _eventlet: http://eventlet.net/
 
-By default, coverage does not measure code installed with the Python
+By default, coverage.py does not measure code installed with the Python
 interpreter, for example, the standard library. If you want to measure that
 code as well as your own, add the ``-L`` flag.
 
 If your coverage results seem to be overlooking code that you know has been
-executed, try running coverage again with the ``--timid`` flag.  This uses a
+executed, try running coverage.py again with the ``--timid`` flag.  This uses a
 simpler but slower trace method.  Projects that use DecoratorTools, including
 TurboGears, will need to use ``--timid`` to get correct results.
 
@@ -149,7 +149,7 @@ could affect the measurement process.  The possible warnings include:
 
 .. _cmd_run_debug:
 
-The ``--debug`` option instructs coverage to log internal details of its
+The ``--debug`` option instructs coverage.py to log internal details of its
 operation, to help with diagnosing problems.  It takes a comma-separated list
 of options, each indicating a facet of operation to log to stderr:
 
@@ -172,8 +172,8 @@ of options, each indicating a facet of operation to log to stderr:
 Data file
 ---------
 
-Coverage collects execution data in a file called ".coverage".  If need be, you
-can set a new file name with the COVERAGE_FILE environment variable.
+Coverage.py collects execution data in a file called ".coverage".  If need be,
+you can set a new file name with the COVERAGE_FILE environment variable.
 
 By default,each run of your program starts with an empty data set. If you need
 to run your program multiple times to get complete data (for example, because
@@ -191,9 +191,9 @@ Combining data files
 --------------------
 
 If you need to collect coverage data from different machines or processes,
-coverage can combine multiple files into one for reporting. Use the ``-p`` flag
-during execution to append distinguishing information to the .coverage data
-file name.
+coverage.py can combine multiple files into one for reporting. Use the ``-p``
+flag during execution to append distinguishing information to the .coverage
+data file name.
 
 Once you have created a number of these files, you can copy them all to a
 single directory, and use the **combine** command to combine them into one
@@ -202,9 +202,9 @@ single directory, and use the **combine** command to combine them into one
     $ coverage combine
 
 If the different machines run your code from different places in their file
-systems, coverage won't know how to combine the data.  You can tell coverage
-how the different locations correlate with a ``[paths]`` section in your
-configuration file.  See :ref:`config_paths` for details.
+systems, coverage.py won't know how to combine the data.  You can tell
+coverage.py how the different locations correlate with a ``[paths]`` section in
+your configuration file.  See :ref:`config_paths` for details.
 
 If you are collecting and renaming your own data files, you'll need to name
 them properly for **combine** to find them.   It looks for files named after
@@ -222,7 +222,7 @@ Here are some examples of data files that can be combined::
 Reporting
 ---------
 
-Coverage provides a few styles of reporting, with the **report**, **html**,
+Coverage.py provides a few styles of reporting, with the **report**, **html**,
 **annotate**, and **xml** commands.  They share a number of common options.
 
 The command-line arguments are module or file names to report on, if you'd like
@@ -307,7 +307,7 @@ Other common reporting options are described above in :ref:`cmd_reporting`.
 HTML annotation
 ---------------
 
-Coverage can annotate your source code for which lines were executed
+Coverage.py can annotate your source code for which lines were executed
 and which were not.  The **html** command creates an HTML report similar to the
 **report** summary, but as an HTML file.  Each module name links to the source
 file decorated to show the status of each line.
diff --git a/doc/conf.py b/doc/conf.py
index 9d55e9d..c996bda 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -46,7 +46,7 @@ source_suffix = '.rst'
 master_doc = 'index'
 
 # General information about the project.
-project = u'coverage.py'
+project = u'Coverage.py'
 copyright = u'2009\N{EN DASH}2015, Ned Batchelder'
 
 # The version info for the project you're documenting, acts as replacement for
diff --git a/doc/config.rst b/doc/config.rst
index df703ba..7109fb8 100644
--- a/doc/config.rst
+++ b/doc/config.rst
@@ -15,7 +15,7 @@ Configuration files
 
 
 Coverage.py options can be specified in a configuration file.  This makes it
-easier to re-run coverage with consistent settings, and also allows for
+easier to re-run coverage.py with consistent settings, and also allows for
 specification of options that are otherwise only available in the
 :ref:`API <api>`.
 
@@ -105,7 +105,7 @@ standard library.
 ``concurrency`` (string, default "thread"): the name of the concurrency
 library in use by the product code.  If your program uses `gevent`_,
 `greenlet`_, or `eventlet`_, you must name that library in this option, or
-coverage will produce very wrong results.
+coverage.py will produce very wrong results.
 
 .. _greenlet: http://greenlet.readthedocs.org/en/latest/
 .. _gevent: http://www.gevent.org/
diff --git a/doc/excluding.rst b/doc/excluding.rst
index 44c51f9..c306ad4 100644
--- a/doc/excluding.rst
+++ b/doc/excluding.rst
@@ -1,8 +1,8 @@
 .. _excluding:
 
-============================
-Excluding code from coverage
-============================
+===============================
+Excluding code from coverage.py
+===============================
 
 .. :history: 20090613T090500, brand new docs.
 .. :history: 20100224T200900, updated for 3.3.
@@ -11,13 +11,13 @@ Excluding code from coverage
 
 
 You may have code in your project that you know won't be executed, and you want
-to tell coverage to ignore it.  For example, you may have debugging-only code
-that won't be executed during your unit tests. You can tell coverage to exclude
-this code during reporting so that it doesn't clutter your reports with noise
-about code that you don't need to hear about.
+to tell coverage.py to ignore it.  For example, you may have debugging-only
+code that won't be executed during your unit tests. You can tell coverage.py to
+exclude this code during reporting so that it doesn't clutter your reports with
+noise about code that you don't need to hear about.
 
-Coverage will look for comments marking clauses for exclusion.  In this code,
-the "if debug" clause is excluded from reporting::
+Coverage.py will look for comments marking clauses for exclusion.  In this
+code, the "if debug" clause is excluded from reporting::
 
     a = my_function1()
     if debug:   # pragma: no cover
@@ -39,7 +39,7 @@ function is not reported as missing::
             return "<MyObject>"
 
 Excluded code is executed as usual, and its execution is recorded in the
-coverage data as usual. When producing reports though, coverage excludes it
+coverage data as usual. When producing reports though, coverage.py excludes it
 from the list of missing code.
 
 
@@ -64,7 +64,7 @@ line, so it isn't considered a branch at all.
 Advanced exclusion
 ------------------
 
-Coverage identifies exclusions by matching lines against a list of regular
+Coverage.py identifies exclusions by matching lines against a list of regular
 expressions. Using :ref:`configuration files <config>` or the coverage
 :ref:`API <api>`, you can add to that list. This is useful if you have
 often-used constructs to exclude that can be matched with a regex. You can
diff --git a/doc/faq.rst b/doc/faq.rst
index 3249253..2bae33d 100644
--- a/doc/faq.rst
+++ b/doc/faq.rst
@@ -26,10 +26,10 @@ the :ref:`command line <cmd>` to create the reports you need from that data.
 
 **Q: Why do unexecutable lines show up as executed?**
 
-Usually this is because you've updated your code and run coverage on it again
-without erasing the old data.  Coverage records line numbers executed, so the
-old data may have recorded a line number which has since moved, causing
-coverage to claim a line has been executed which cannot be.
+Usually this is because you've updated your code and run coverage.py on it
+again without erasing the old data.  Coverage.py records line numbers executed,
+so the old data may have recorded a line number which has since moved, causing
+coverage.py to claim a line has been executed which cannot be.
 
 If you are using the ``-x`` command line action, it doesn't erase first by
 default.  Switch to the ``coverage run`` command, or use the ``-e`` switch to
@@ -39,18 +39,18 @@ erase all data before starting the next run.
 **Q: Why do the bodies of functions (or classes) show as executed, but the def
 lines do not?**
 
-This happens because coverage is started after the functions are defined.  The
-definition lines are executed without coverage measurement, then coverage is
-started, then the function is called.  This means the body is measured, but
-the definition of the function itself is not.
+This happens because coverage.py is started after the functions are defined.
+The definition lines are executed without coverage measurement, then
+coverage.py is started, then the function is called.  This means the body is
+measured, but the definition of the function itself is not.
 
-To fix this, start coverage earlier.  If you use the :ref:`command line <cmd>`
-to run your program with coverage, then your entire program will be monitored.
-If you are using the :ref:`API <api>`, you need to call coverage.start() before
-importing the modules that define your functions.
+To fix this, start coverage.py earlier.  If you use the :ref:`command line
+<cmd>` to run your program with coverage.py, then your entire program will be
+monitored.  If you are using the :ref:`API <api>`, you need to call
+coverage.start() before importing the modules that define your functions.
 
 
-**Q: Coverage is much slower than I remember, what's going on?**
+**Q: Coverage.py is much slower than I remember, what's going on?**
 
 Make sure you are using the C trace function.  Coverage.py provides two
 implementations of the trace function.  The C implementation runs much faster.
diff --git a/doc/index.rst b/doc/index.rst
index 49da94e..af24493 100644
--- a/doc/index.rst
+++ b/doc/index.rst
@@ -1,5 +1,5 @@
 ===========
-coverage.py
+Coverage.py
 ===========
 
 .. :history: 20090524T134300, brand new docs.
@@ -65,7 +65,7 @@ Quick start
 
 Getting started is easy:
 
-#.  Install coverage.py from the `coverage page on the Python Package Index`_,
+#.  Install coverage.py from the `coverage.py page on the Python Package Index`_,
     or by using "pip install coverage".  For a few more details, see
     :ref:`install`.
 
@@ -105,7 +105,7 @@ Getting started is easy:
         Then visit htmlcov/index.html in your browser, to see a
         `report like this one`_.
 
-.. _coverage page on the Python Package Index: http://pypi.python.org/pypi/coverage
+.. _coverage.py page on the Python Package Index: http://pypi.python.org/pypi/coverage
 .. _report like this: http://nedbatchelder.com/code/coverage/sample_html/index.html
 .. _report like this one: http://nedbatchelder.com/code/coverage/sample_html_beta/index.html
 
@@ -118,12 +118,12 @@ There are a few different ways to use coverage.py.  The simplest is the
 If you need more control over how your project is measured, you can use the
 :ref:`API <api>`.
 
-Some test runners provide coverage integration to make it easy to use coverage
-while running tests.  For example, `nose`_ has a `cover plug-in`_.
+Some test runners provide coverage integration to make it easy to use
+coverage.py while running tests.  For example, `nose`_ has a `cover plug-in`_.
 
-You can fine-tune coverage's view of your code by directing it to ignore parts
-that you know aren't interesting.  See :ref:`source` and :ref:`excluding` for
-details.
+You can fine-tune coverage.py's view of your code by directing it to ignore
+parts that you know aren't interesting.  See :ref:`source` and :ref:`excluding`
+for details.
 
 .. _nose:           http://somethingaboutorange.com/mrl/projects/nose
 .. _cover plug-in:  https://nose.readthedocs.org/en/latest/plugins/cover.html
@@ -173,7 +173,3 @@ More information
     trouble
     faq
     changes
-
-
-.. How it works
-.. .coverage file format
diff --git a/doc/install.rst b/doc/install.rst
index 67af720..fa01e63 100644
--- a/doc/install.rst
+++ b/doc/install.rst
@@ -47,7 +47,7 @@ The alternate old-school technique is:
 #.  Install (or already have installed) `setuptools`_ or `Distribute`_.
 
 #.  Download the appropriate kit from the
-    `coverage page on the Python Package Index`__.
+    `coverage.py page on the Python Package Index`__.
 
 #.  Run ``python setup.py install``.
 
@@ -82,8 +82,8 @@ the C extension pre-compiled so there's no need to worry about compilers.
 Checking the installation
 -------------------------
 
-If all went well, you should be able to open a command prompt, and see coverage
-installed properly:
+If all went well, you should be able to open a command prompt, and see
+coverage.py installed properly:
 
 .. ifconfig:: not prerelease
 
@@ -101,7 +101,7 @@ installed properly:
         Coverage.py, version |release|.
         Documentation at https://coverage.readthedocs.org/en/|release|
 
-You can also invoke coverage as a module:
+You can also invoke coverage.py as a module:
 
 .. ifconfig:: not prerelease
 
diff --git a/doc/subprocess.rst b/doc/subprocess.rst
index cce2c0b..92ad135 100644
--- a/doc/subprocess.rst
+++ b/doc/subprocess.rst
@@ -30,7 +30,7 @@ Measuring coverage in sub-processes is a little tricky.  When you spawn a
 sub-process, you are invoking Python to run your program.  Usually, to get
 coverage measurement, you have to use coverage.py to run your program.  Your
 sub-process won't be using coverage.py, so we have to convince Python to use
-coverage even when not explicitly invoked.
+coverage.py even when not explicitly invoked.
 
 To do that, we'll configure Python to run a little coverage.py code when it
 starts.  That code will look for an environment variable that tells it to start
diff --git a/doc/trouble.rst b/doc/trouble.rst
index c54ab68..dbb22ac 100644
--- a/doc/trouble.rst
+++ b/doc/trouble.rst
@@ -8,8 +8,8 @@ Things that cause trouble
 .. :history: 20150124T160800, remove obsolete stuff.
 
 
-Coverage works well, and I want it to properly measure any Python program, but
-there are some situations it can't cope with.  This page details some known
+Coverage.py works well, and I want it to properly measure any Python program,
+but there are some situations it can't cope with.  This page details some known
 problems, with possible courses of action, and links to coverage.py bug reports
 with more information.