@@ -64,7 +64,7 @@ Simple Example
64
64
This shows a very simple example of how the logging package can be
65
65
used to generate simple logging output on stderr.
66
66
67
- ::
67
+ .. code-block:: python
68
68
69
69
--------- mymodule.py -------------------------------
70
70
import logging
@@ -76,6 +76,8 @@ used to generate simple logging output on stderr.
76
76
raise TypeError, "Bogus type error for testing"
77
77
-----------------------------------------------------
78
78
79
+ .. code-block:: python
80
+
79
81
--------- myapp.py ----------------------------------
80
82
import mymodule, logging
81
83
@@ -91,7 +93,9 @@ used to generate simple logging output on stderr.
91
93
log.info("Ending my app")
92
94
-----------------------------------------------------
93
95
94
- % python myapp.py
96
+ .. code-block:: console
97
+
98
+ $ python myapp.py
95
99
96
100
INFO:MyApp: Starting my app
97
101
DEBUG:MyModule: Doin' stuff...
@@ -107,7 +111,9 @@ used to generate simple logging output on stderr.
107
111
108
112
The above example shows the default output format. All
109
113
aspects of the output format should be configurable, so that
110
- you could have output formatted like this::
114
+ you could have output formatted like this:
115
+
116
+ .. code-block:: text
111
117
112
118
2002-04-19 07:56:58,174 MyModule DEBUG - Doin' stuff...
113
119
@@ -127,11 +133,9 @@ Logger names fit into a "dotted name" namespace, with dots
127
133
(periods) indicating sub-namespaces. The namespace of logger
128
134
objects therefore corresponds to a single tree data structure.
129
135
130
- ::
131
-
132
- "" is the root of the namespace
133
- "Zope" would be a child node of the root
134
- "Zope.ZODB" would be a child node of "Zope"
136
+ * ``""`` is the root of the namespace
137
+ * ``"Zope"`` would be a child node of the root
138
+ * ``"Zope.ZODB"`` would be a child node of ``"Zope"``
135
139
136
140
These Logger objects create **LogRecord** objects which are passed
137
141
to **Handler** objects for output. Both Loggers and Handlers may
@@ -170,13 +174,13 @@ This is done through a module-level function::
170
174
Levels
171
175
======
172
176
173
- The logging levels, in increasing order of importance, are::
177
+ The logging levels, in increasing order of importance, are:
174
178
175
- DEBUG
176
- INFO
177
- WARN
178
- ERROR
179
- CRITICAL
179
+ * DEBUG
180
+ * INFO
181
+ * WARN
182
+ * ERROR
183
+ * CRITICAL
180
184
181
185
The term CRITICAL is used in preference to FATAL, which is used by
182
186
log4j. The levels are conceptually the same - that of a serious,
0 commit comments