[LNT] r367923 - [LNT] Wrap comments and docstrings at 72 chars
Thomas Preud'homme via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 5 13:33:48 PDT 2019
Author: thopre
Date: Mon Aug 5 13:33:48 2019
New Revision: 367923
URL: http://llvm.org/viewvc/llvm-project?rev=367923&view=rev
Log:
[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
Modified:
lnt/trunk/lnt/testing/__init__.py
Modified: lnt/trunk/lnt/testing/__init__.py
URL: http://llvm.org/viewvc/llvm-project/lnt/trunk/lnt/testing/__init__.py?rev=367923&r1=367922&r2=367923&view=diff
==============================================================================
--- lnt/trunk/lnt/testing/__init__.py (original)
+++ lnt/trunk/lnt/testing/__init__.py Mon Aug 5 13:33:48 2019
@@ -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.
+ 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.
+ 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):
More information about the llvm-commits
mailing list