Commits

Ned Batchelder  committed 77d0a75

Remove notes about me being available for custom work, and rewrap many paragraphs.

  • Participants
  • Parent commits a567885

Comments (0)

Files changed (12)

 
 The API to coverage.py is very simple, contained in a single module called
 `coverage`.  Most of the interface is in a single class, also called
-`coverage`.  Methods on the coverage object correspond roughly to operations available
-in the command line interface. For example, a simple use would be::
+`coverage`.  Methods on the coverage object correspond roughly to operations
+available in the command line interface. For example, a simple use would be::
 
     import coverage
 

File doc/branch.rst

 Excluding code
 --------------
 
-If you have :ref:`excluded code <excluding>`, a condtional will not be
-counted as a branch if one of its choices is excluded::
+If you have :ref:`excluded code <excluding>`, a condtional will not be counted
+as a branch if one of its choices is excluded::
 
     def only_one_choice(x):
         if x:
             # x is always true.
             blah3()
 
-Because the ``else`` clause is excluded, the ``if`` only has one possible
-next line, so it isn't considered a branch at all.
+Because the ``else`` clause is excluded, the ``if`` only has one possible next
+line, so it isn't considered a branch at all.
 
 
 Structurally partial branches
             break
 
 Here the while loop will never complete because the break will always be taken
-at some point.  Coverage.py can't work that out on its own, but the
-"no branch" pragma indicates that the branch is known to be partial, and
-the line is not flagged.
+at some point.  Coverage.py can't work that out on its own, but the "no branch"
+pragma indicates that the branch is known to be partial, and the line is not
+flagged.
 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 .coverage
-data file::
+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
+.coverage data file::
 
     $ coverage combine
 
 Text annotation
 ---------------
 
-The **annotate** command produces a text annotation of your source code.  With a
-``-d`` argument specifying an output directory, each Python file becomes a text
-file in that directory.  Without ``-d``, the files are written into the same
-directories as the original Python files.
+The **annotate** command produces a text annotation of your source code.  With
+a ``-d`` argument specifying an output directory, each Python file becomes a
+text file in that directory.  Without ``-d``, the files are written into the
+same directories as the original Python files.
 
 Coverage status for each line of source is indicated with a character prefix::
 

File doc/config.rst

 
 The default name for configuration files is ``.coveragerc``, in the same
 directory coverage.py is being run in.  Most of the settings in the
-configuration file are tied to your source code and how it should be
-measured, so it should be stored with your source, and checked into
-source control, rather than put in your home directory.
+configuration file are tied to your source code and how it should be measured,
+so it should be stored with your source, and checked into source control,
+rather than put in your home directory.
 
 
 Syntax
 [paths]
 -------
 
-The entries in this section are lists of file paths that should be
-considered equivalent when combining data from different machines::
+The entries in this section are lists of file paths that should be considered
+equivalent when combining data from different machines::
 
     [paths]
     source =
         /jenkins/build/*/src
         c:\myproj\src
 
-The names of the entries are ignored, you may choose any name that
-you like.  The value is a lists of strings.  When combining data
-with the ``combine`` command, two file paths will be combined
-if they start with paths from the same list.
+The names of the entries are ignored, you may choose any name that you like.
+The value is a lists of strings.  When combining data with the ``combine``
+command, two file paths will be combined if they start with paths from the same
+list.
 
-The first value must be an actual file path on the machine where
-the reporting will happen, so that source code can be found.
-The other values can be file patterns to match against the paths
-of collected data.
+The first value must be an actual file path on the machine where the reporting
+will happen, so that source code can be found.  The other values can be file
+patterns to match against the paths of collected data.
 
 See :ref:`cmd_combining` for more information.
 
 supply the "pragma: no branch" regex if you still want to use it.
 
 ``precision`` (integer): the number of digits after the decimal point to
-display for reported coverage percentages.  The default is 0, displaying
-for example "87%".  A value of 2 will display percentages like "87.32%".
+display for reported coverage percentages.  The default is 0, displaying for
+example "87%".  A value of 2 will display percentages like "87.32%".
 
-``show_missing`` (boolean, default False): when running a summary report,
-show missing lines.  See :ref:`cmd_summary` for more information.
+``show_missing`` (boolean, default False): when running a summary report, show
+missing lines.  See :ref:`cmd_summary` for more information.
 
 
 .. _config_html:

File doc/contributing.rst

     (and so on...)
 
 Tox runs the complete test suite twice for each version of Python you have
-installed.  The first run uses the Python implementation of the trace
-function, the second uses the C implementation.
+installed.  The first run uses the Python implementation of the trace function,
+the second uses the C implementation.
 
 To limit tox to just a few versions of Python, use the ``-e`` switch::
 
 
     $ tox tests.test_misc:SetupPyTest.test_metadata
 
-This looks in `tests/test_misc.py` to find the `SetupPyTest` class, and runs the
-`test_metadata` test method.
+This looks in `tests/test_misc.py` to find the `SetupPyTest` class, and runs
+the `test_metadata` test method.
 
 Of course, run all the tests on every version of Python you have, before
 submitting a change.

File doc/excluding.rst

             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 from
-the list of missing code.
+coverage data as usual. When producing reports though, coverage excludes it
+from the list of missing code.
 
 
 Branch coverage
             # x is always true.
             blah3()
 
-Because the ``else`` clause is excluded, the ``if`` only has one possible
-next line, so it isn't considered a branch at all.
+Because the ``else`` clause is excluded, the ``if`` only has one possible next
+line, so it isn't considered a branch at all.
 
 
 Advanced exclusion
 often-used constructs to exclude that can be matched with a regex. You can
 exclude them all at once without littering your code with exclusion pragmas.
 
-For example, you might decide that __repr__ functions are usually only used
-in debugging code, and are uninteresting to test themselves.  You could exclude
+For example, you might decide that __repr__ functions are usually only used in
+debugging code, and are uninteresting to test themselves.  You could exclude
 all of them by adding a regex to the exclusion list::
 
     [report]
 
 **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
+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.
 
 If you are using the ``-x`` command line action, it doesn't erase first by
 .. _coveragepy-announce: http://groups.google.com/group/coveragepy-announce
 
 `I can be reached`__ in a number of ways, I'm happy to answer questions about
-using coverage.py.  I'm also available hourly for consultation or custom
-development.
+using coverage.py.
 
 __  http://nedbatchelder.com/site/aboutned.html
 

File doc/index.rst

 .. _code repository: http://bitbucket.org/ned/coveragepy
 
 `I can be reached`_ in a number of ways. I'm happy to answer questions about
-using coverage.py.  I'm also available hourly for consultation or custom
-development.
+using coverage.py.
 
 .. _I can be reached:  http://nedbatchelder.com/site/aboutned.html
 

File doc/install.rst

 Installing from source
 ----------------------
 
-Coverage.py includes a C extension for speed. If you are installing from source,
-you may need to install the python-dev support files, for example with::
+Coverage.py includes a C extension for speed. If you are installing from
+source, you may need to install the python-dev support files, for example
+with::
 
     $ sudo apt-get install python-dev
 
 ---------------------
 
 For Windows, kits are provided on the `PyPI page`__ for different versions of
-Python and different CPU architectures. These kits require that `setuptools`_ be
-installed as a pre-requisite, but otherwise are self-contained.  They have the
-C extension pre-compiled so there's no need to worry about compilers.
+Python and different CPU architectures. These kits require that `setuptools`_
+be installed as a pre-requisite, but otherwise are self-contained.  They have
+the C extension pre-compiled so there's no need to worry about compilers.
 
 .. __: coverage_pypi_
 
 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
+installed properly::
 
     $ coverage --version
     Coverage.py, version 3.6.  http://nedbatchelder.com/code/coverage

File doc/source.rst

 When running your code, the ``coverage run`` command will by default measure
 all code, unless it is part of the Python standard library.
 
-You can specify source to measure with the ``--source`` command-line switch,
-or the ``[run] source`` configuration value.  The value is a list of directories
+You can specify source to measure with the ``--source`` command-line switch, or
+the ``[run] source`` configuration value.  The value is a list of directories
 or package names.  If specified, only source inside these directories or
 packages will be measured.  Specifying the source option also enables
 coverage.py to report on unexecuted files, since it can search the source tree

File doc/subprocess.rst

 
 Measuring coverage in subprocesses is a little tricky.  When you spawn a
 subprocess, you are invoking Python to run your program.  Usually, to get
-coverage measurement, you have to use coverage.py to run your program.
-Your subprocess won't be using coverage.py, so we have to convince Python
-to use coverage even when not explicitly invokved.
+coverage measurement, you have to use coverage.py to run your program.  Your
+subprocess won't be using coverage.py, so we have to convince Python to use
+coverage even when not explicitly invokved.
 
 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 coverage measurement at the start of the process.
+starts.  That code will look for an environment variable that tells it to start
+coverage measurement at the start of the process.
 
 To arrange all this, you have to do two things: set a value for the
 ``COVERAGE_PROCESS_START`` environment variable, and then configure Python to
 invoke :func:`coverage.process_startup` when Python processes start.
 
 How you set ``COVERAGE_PROCESS_START`` depends on the details of how you create
-subprocesses.  As long as the environment variable is visible in your subprocess,
-it will work.
+subprocesses.  As long as the environment variable is visible in your
+subprocess, it will work.
 
 You can configure your Python installation to invoke the ``process_startup``
 function in two ways:
 
     import coverage; coverage.process_startup()
 
-The sitecustomize.py technique is cleaner, but may involve modifying an existing
-sitecustomize.py, since there can be only one.  If there is no sitecustomize.py
-already, you can create it in any directory on the Python path.
+The sitecustomize.py technique is cleaner, but may involve modifying an
+existing sitecustomize.py, since there can be only one.  If there is no
+sitecustomize.py already, you can create it in any directory on the Python
+path.
 
 The .pth technique seems like a hack, but works, and is documented behavior.
 On the plus side, you can create the file with any name you like so you don't
-have to coordinate with other .pth files.  On the minus side, you have to create
-the file in a system-defined directory, so you may need privileges to write it.
+have to coordinate with other .pth files.  On the minus side, you have to
+create the file in a system-defined directory, so you may need privileges to
+write it.
 
 Note that if you use one of these techniques, you must undo them if you
 uninstall coverage.py, since you will be trying to import it during Python

File doc/trouble.rst

 problems, with possible courses of action, and links to coverage.py bug reports
 with more information.
 
-I would love to :ref:`hear from you <contact>` if you have information about any of
-these problems, even just to explain to me why you want them to start working
-properly.
+I would love to :ref:`hear from you <contact>` if you have information about
+any of these problems, even just to explain to me why you want them to start
+working properly.
 
 If your problem isn't discussed here, you can of course search the `coverage.py
 bug tracker`_ directly to see if there is some mention of it.
 ---------------------
 
 * Python 2.5 had a bug (`1569356`_) that could make your program behave
-  differently when being measured with coverage.  This is diagnosed in `issue 51`_.
+  differently when being measured with coverage.  This is diagnosed in
+  `issue 51`_.
 
 .. _issue 51: http://bitbucket.org/ned/coveragepy/issue/51/turbogears-15-test-failing-with-coverage
 .. _1569356: http://bugs.python.org/issue1569356
 Still having trouble?
 ---------------------
 
-If your problem isn't mentioned here, and isn't already reported in the `coverage.py bug tracker`_,
-please :ref:`get in touch with me <contact>`, we'll figure out a solution.
+If your problem isn't mentioned here, and isn't already reported in the
+`coverage.py bug tracker`_, please :ref:`get in touch with me <contact>`,
+we'll figure out a solution.