20
20
function runs. Import statements have a cost, so try to make sure
21
21
they don't run inside hot functions.
23
* Please write PEP-8__ compliant code.
23
* Please write PEP-8__ compliant code.
25
One often-missed requirement is that the first line of docstrings
26
should be a self-contained one-sentence summary.
25
28
__ http://www.python.org/peps/pep-0008.html
41
44
mentioned, but new commands, changes in behaviour or fixed nontrivial
42
45
bugs should be listed. See the existing entries for an idea of what
53
(The strategy described here is what we want to get to, but it's not
54
consistently followed in the code at the moment.)
56
bzrlib is intended to be a generically reusable library. It shouldn't
57
write messages to stdout or stderr, because some programs that use it
58
might want to display that information through a GUI or some other
61
We can distinguish two types of output from the library:
63
1. Structured data representing the progress or result of an
64
operation. For example, for a commit command this will be a list
65
of the modified files and the finally committed revision number
68
These should be exposed either through the return code or by calls
69
to a callback parameter.
71
A special case of this is progress indicators for long-lived
72
operations, where the caller should pass a ProgressBar object.
74
2. Unstructured log/debug messages, mostly for the benefit of the
75
developers or users trying to debug problems. This should always
76
be sent through ``bzrlib.trace`` and Python ``logging``, so that
77
it can be redirected by the client.
79
The distinction between the two is a bit subjective, but in general if
80
there is any chance that a library would want to see something as
81
structured data, we should make it so.
83
The policy about how output is presented in the text-mode client
84
should be only in the command-line tool.
added
removed
HACKING
