summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorNed Batchelder <ned@nedbatchelder.com>2014-11-27 10:36:16 -0500
committerNed Batchelder <ned@nedbatchelder.com>2014-11-27 10:36:16 -0500
commit1fa418c6c1c33117308e3d94f18f8fc1a9193393 (patch)
tree3502c943b2a3da2c41a4b59faf002db94cf3f9ac /doc
parenta8f8bb898ac35acd493524d470223319b2271f4a (diff)
downloadpython-coveragepy-git-1fa418c6c1c33117308e3d94f18f8fc1a9193393.tar.gz
Try out pylint spelling. Kinda noisy, but fixed some stuff.
Diffstat (limited to 'doc')
-rw-r--r--doc/changes.rst6
-rw-r--r--doc/index.rst2
-rw-r--r--doc/subprocess.rst26
3 files changed, 17 insertions, 17 deletions
diff --git a/doc/changes.rst b/doc/changes.rst
index b9980af8..a16c544c 100644
--- a/doc/changes.rst
+++ b/doc/changes.rst
@@ -281,8 +281,8 @@ Version 3.5.3 --- 29 September 2012
`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 subdirectories do, to
- be considered as source files.
+ 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.
@@ -701,7 +701,7 @@ Version 3.0 --- 13 June 2009
- The minimum supported Python version is 2.3.
-- When using the object api (that is, constructing a coverage() object), data
+- When using the object API (that is, constructing a coverage() object), data
is no longer saved automatically on process exit. You can re-enable it with
the ``auto_data=True`` parameter on the coverage() constructor.
The module-level interface still uses automatic saving.
diff --git a/doc/index.rst b/doc/index.rst
index ba83f2cd..68780ea5 100644
--- a/doc/index.rst
+++ b/doc/index.rst
@@ -139,7 +139,7 @@ coverage.py or get help using it on the `Testing In Python`_ mailing list.
Bug reports are gladly accepted at the `Bitbucket issue tracker`_.
Bitbucket also hosts the `code repository`_. There is a `mirrored repo`_ on
-Github.
+GitHub.
.. _Bitbucket issue tracker: http://bitbucket.org/ned/coveragepy/issues
.. _code repository: http://bitbucket.org/ned/coveragepy
diff --git a/doc/subprocess.rst b/doc/subprocess.rst
index a4e759d7..40875f7f 100644
--- a/doc/subprocess.rst
+++ b/doc/subprocess.rst
@@ -1,16 +1,16 @@
.. _subprocess:
-======================
-Measuring subprocesses
-======================
+=======================
+Measuring sub-processes
+=======================
:history: 20100224T201800, new for 3.3.
:history: 20100725T211700, updated for 3.4.
-Complex test suites may spawn subprocesses to run tests, either to run them in
-parallel, or because subprocess behavior is an important part of the system
-under test. Measuring coverage in those subprocesses can be tricky because you
+Complex test suites may spawn sub-processes to run tests, either to run them in
+parallel, or because sub-process behavior is an important part of the system
+under test. Measuring coverage in those sub-processes can be tricky because you
have to modify the code spawning the process to invoke coverage.py.
There's an easier way to do it: coverage.py includes a function,
@@ -23,13 +23,13 @@ When using this technique, be sure to set the parallel option to true so that
multiple coverage.py runs will each write their data to a distinct file.
-Configuring Python for subprocess coverage
-------------------------------------------
+Configuring Python for sub-process coverage
+-------------------------------------------
-Measuring coverage in subprocesses is a little tricky. When you spawn a
-subprocess, you are invoking Python to run your program. Usually, to get
+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
-subprocess won't be using coverage.py, so we have to convince Python to use
+sub-process 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
@@ -41,8 +41,8 @@ To arrange all this, you have to do two things: set a value for the
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.
+sub-processes. As long as the environment variable is visible in your
+sub-process, it will work.
You can configure your Python installation to invoke the ``process_startup``
function in two ways: