[LNT] Wrap comments and docstrings at 72 chars

As per PEP-008, wrap comments and docstrings in the test data creation
library at 72 characters.

Differential Revision: https://reviews.llvm.org/D65749


git-svn-id: https://llvm.org/svn/llvm-project/lnt/trunk@367923 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 49 insertions, 48 deletions

diff --git a/lnt/testing/__init__.py b/lnt/testing/__init__.py
index 6fbc792..1ae63f9 100644
--- a/lnt/testing/__init__.py
+++ b/lnt/testing/__init__.py
@@ -1,9 +1,9 @@
 """
 Utilities for working with the LNT test format.
 
-Clients can easily generate LNT test format data by creating Report objects for
-the runs they wish to submit, and using Report.render to convert them to JSON
-data suitable for submitting to the server.
+Clients can easily generate LNT test format data by creating Report
+objects for the runs they wish to submit, and using Report.render to
+convert them to JSON data suitable for submitting to the server.
 """
 
 import datetime
@@ -15,7 +15,8 @@ try:
 except ImportError:
     import simplejson as json
 
-# We define the following constants for use as sample values by convention.
+# We define the following constants for use as sample values by
+# convention.
 PASS = 0
 FAIL = 1
 XFAIL = 2
@@ -32,8 +33,8 @@ def normalize_time(t):
 class Report:
     """Information on a single testing run.
 
-    In the LNT test model, every test run should define exactly one machine and
-    run, and any number of test samples.
+    In the LNT test model, every test run should define exactly one
+    machine and run, and any number of test samples.
     """
     def __init__(self, machine, run, tests):
         self.machine = machine
@@ -49,9 +50,7 @@ class Report:
             assert isinstance(t, TestSamples)
 
     def update_report(self, new_samples):
-        """Add extra samples to this report, and update
-        the end time.
-        """
+        """Add extra samples to this report, and update the end time."""
         self.check()
         self.tests.extend(new_samples)
         self.run.update_endtime()
@@ -59,8 +58,8 @@ class Report:
 
     def render(self, indent=4):
         # Note that we specifically override the encoding to avoid the
-        # possibility of encoding errors. Clients which care about the text
-        # encoding should supply unicode string objects.
+        # possibility of encoding errors. Clients which care about the
+        # text encoding should supply unicode string objects.
         return json.dumps({'Machine': self.machine.render(),
                            'Run': self.run.render(),
                            'Tests': [t.render() for t in self.tests]},
@@ -70,12 +69,12 @@ class Report:
 class Machine:
     """Information on the machine the test was run on.
 
-    The info dictionary can be used to describe additional information about
-    the machine, for example the hardware resources or the operating
-    environment.
+    The info dictionary can be used to describe additional information
+    about the machine, for example the hardware resources or the
+    operating environment.
 
-    Machines entries in the database are uniqued by their name and the entire
-    contents of the info dictionary.
+    Machines entries in the database are uniqued by their name and the
+    entire contents of the info dictionary.
     """
     def __init__(self, name, info={}):
         self.name = str(name)
@@ -90,16 +89,18 @@ class Machine:
 class Run:
     """Information on the particular test run.
 
-    The start and end time should always be supplied with the run. Currently,
-    the server uses these to order runs. In the future we will support
-    additional ways to order runs (for example, by a source revision).
-
-    As with Machine, the info dictionary can be used to describe additional
-    information on the run. This dictionary should be used to describe
-    information on the software-under-test that is constant across the test
-    run, for example the revision number being tested. It can also be used to
-    describe information about the current state which could be useful in
-    analysis, for example the current machine load.
+    The start and end time should always be supplied with the run.
+    Currently, the server uses these to order runs. In the future we
+    will support additional ways to order runs (for example, by a source
+    revision).
+
+    As with Machine, the info dictionary can be used to describe
+    additional information on the run. This dictionary should be used to
+    describe information on the software-under-test that is constant
+    across the test run, for example the revision number being tested.
+    It can also be used to describe information about the current state
+    which could be useful in analysis, for example the current machine
+    load.
     """
     def __init__(self, start_time, end_time, info={}):
         if start_time is None:
@@ -135,28 +136,28 @@ class TestSamples:
     """Test sample data.
 
     The test sample data defines both the tests that were run and their
-    values. The server automatically creates test database objects whenever a
-    new test name is seen.
-
-    Test names are intended to be a persistent, recognizable identifier for
-    what is being executed. Currently, most formats use some form of dotted
-    notation for the test name, and this may become enshrined in the format in
-    the future. In general, the test names should be independent of the
-    software-under-test and refer to some known quantity, for example the
-    software under test. For example, 'CINT2006.403_gcc' is a meaningful test
-    name.
-
-    The test info dictionary is intended to hold information on the particular
-    permutation of the test that was run. This might include variables specific
-    to the software-under-test . This could include, for example, the compile
-    flags the test was built with, or the runtime parameters that were used. As
-    a general rule, if two test samples are meaningfully and directly
-    comparable, then the should have the same test name but different info
-    paramaters.
-
-    The report may include an arbitrary number of samples for each test for
-    situations where the same test is run multiple times to gather statistical
-    data.
+    values. The server automatically creates test database objects
+    whenever a new test name is seen.
+
+    Test names are intended to be a persistent, recognizable identifier
+    for what is being executed. Currently, most formats use some form of
+    dotted notation for the test name, and this may become enshrined in
+    the format in the future. In general, the test names should be
+    independent of the software-under-test and refer to some known
+    quantity, for example the software under test. For example,
+    'CINT2006.403_gcc' is a meaningful test name.
+
+    The test info dictionary is intended to hold information on the
+    particular permutation of the test that was run. This might include
+    variables specific to the software-under-test . This could include,
+    for example, the compile flags the test was built with, or the
+    runtime parameters that were used. As a general rule, if two test
+    samples are meaningfully and directly comparable, then they should
+    have the same test name but different info paramaters.
+
+    The report may include an arbitrary number of samples for each test
+    for situations where the same test is run multiple times to gather
+    statistical data.
     """
 
     def __init__(self, name, data, info={}, conv_f=float):