diff options
author | Ned Batchelder <ned@nedbatchelder.com> | 2014-11-27 10:36:16 -0500 |
---|---|---|
committer | Ned Batchelder <ned@nedbatchelder.com> | 2014-11-27 10:36:16 -0500 |
commit | 1fa418c6c1c33117308e3d94f18f8fc1a9193393 (patch) | |
tree | 3502c943b2a3da2c41a4b59faf002db94cf3f9ac /doc | |
parent | a8f8bb898ac35acd493524d470223319b2271f4a (diff) | |
download | python-coveragepy-git-1fa418c6c1c33117308e3d94f18f8fc1a9193393.tar.gz |
Try out pylint spelling. Kinda noisy, but fixed some stuff.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/changes.rst | 6 | ||||
-rw-r--r-- | doc/index.rst | 2 | ||||
-rw-r--r-- | doc/subprocess.rst | 26 |
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: |