blob: 5a4116053a2701d43458fb051b1dc3aab4fb1a8c [file] [log] [blame]
Georg Brandl116aa622007-08-15 14:28:22 +00001:mod:`logging` --- Logging facility for Python
2==============================================
3
4.. module:: logging
Vinay Sajip1d5d6852010-12-12 22:47:13 +00005 :synopsis: Flexible event logging system for applications.
Georg Brandl116aa622007-08-15 14:28:22 +00006
7
8.. moduleauthor:: Vinay Sajip <vinay_sajip@red-dove.com>
9.. sectionauthor:: Vinay Sajip <vinay_sajip@red-dove.com>
10
11
Georg Brandl116aa622007-08-15 14:28:22 +000012.. index:: pair: Errors; logging
13
Vinay Sajipc63619b2010-12-19 12:56:57 +000014.. sidebar:: Important
15
Vinay Sajip01094e12010-12-19 13:41:26 +000016 This page contains the API reference information. For tutorial
17 information and discussion of more advanced topics, see
Vinay Sajipc63619b2010-12-19 12:56:57 +000018
19 * :ref:`Basic Tutorial <logging-basic-tutorial>`
20 * :ref:`Advanced Tutorial <logging-advanced-tutorial>`
21 * :ref:`Logging Cookbook <logging-cookbook>`
22
23
Vinay Sajip1d5d6852010-12-12 22:47:13 +000024This module defines functions and classes which implement a flexible event
Vinay Sajip36675b62010-12-12 22:30:17 +000025logging system for applications and libraries.
Georg Brandl116aa622007-08-15 14:28:22 +000026
Vinay Sajipa18b9592010-12-12 13:20:55 +000027The key benefit of having the logging API provided by a standard library module
28is that all Python modules can participate in logging, so your application log
29can include your own messages integrated with messages from third-party
30modules.
31
Vinay Sajipc63619b2010-12-19 12:56:57 +000032The module provides a lot of functionality and flexibility. If you are
33unfamiliar with logging, the best way to get to grips with it is to see the
Vinay Sajip01094e12010-12-19 13:41:26 +000034tutorials (see the links on the right).
Vinay Sajipa18b9592010-12-12 13:20:55 +000035
Vinay Sajipc63619b2010-12-19 12:56:57 +000036The basic classes defined by the module, together with their functions, are
37listed below.
Vinay Sajip9a6b4002010-12-14 19:40:21 +000038
39* Loggers expose the interface that application code directly uses.
40* Handlers send the log records (created by loggers) to the appropriate
41 destination.
42* Filters provide a finer grained facility for determining which log records
43 to output.
44* Formatters specify the layout of log records in the final output.
Vinay Sajipa18b9592010-12-12 13:20:55 +000045
Georg Brandl116aa622007-08-15 14:28:22 +000046
Vinay Sajipc63619b2010-12-19 12:56:57 +000047.. _logger:
Vinay Sajip5286ccf2010-12-12 13:25:29 +000048
Vinay Sajipc63619b2010-12-19 12:56:57 +000049Logger Objects
Christian Heimes8b0facf2007-12-04 19:30:01 +000050--------------
51
Vinay Sajipc63619b2010-12-19 12:56:57 +000052Loggers have the following attributes and methods. Note that Loggers are never
53instantiated directly, but always through the module-level function
54``logging.getLogger(name)``.
Georg Brandl116aa622007-08-15 14:28:22 +000055
Vinay Sajipc63619b2010-12-19 12:56:57 +000056.. class:: Logger
Georg Brandl116aa622007-08-15 14:28:22 +000057
Vinay Sajipc63619b2010-12-19 12:56:57 +000058.. attribute:: Logger.propagate
Georg Brandl116aa622007-08-15 14:28:22 +000059
Vinay Sajip287f2462011-11-23 08:54:22 +000060 If this evaluates to true, logging messages are passed by this logger and by
61 its child loggers to the handlers of higher level (ancestor) loggers.
62 Messages are passed directly to the ancestor loggers' handlers - neither the
63 level nor filters of the ancestor loggers in question are considered.
64
65 If this evaluates to false, logging messages are not passed to the handlers
66 of ancestor loggers.
67
Benjamin Peterson79ed84c2011-12-30 13:47:25 -060068 The constructor sets this attribute to ``True``.
Vinay Sajipc8c8c692010-09-17 10:09:04 +000069
70
Vinay Sajipc63619b2010-12-19 12:56:57 +000071.. method:: Logger.setLevel(lvl)
Vinay Sajipf234eb92010-12-12 17:37:27 +000072
Vinay Sajipc63619b2010-12-19 12:56:57 +000073 Sets the threshold for this logger to *lvl*. Logging messages which are less
74 severe than *lvl* will be ignored. When a logger is created, the level is set to
75 :const:`NOTSET` (which causes all messages to be processed when the logger is
76 the root logger, or delegation to the parent when the logger is a non-root
77 logger). Note that the root logger is created with level :const:`WARNING`.
78
79 The term 'delegation to the parent' means that if a logger has a level of
80 NOTSET, its chain of ancestor loggers is traversed until either an ancestor with
81 a level other than NOTSET is found, or the root is reached.
82
83 If an ancestor is found with a level other than NOTSET, then that ancestor's
84 level is treated as the effective level of the logger where the ancestor search
85 began, and is used to determine how a logging event is handled.
86
87 If the root is reached, and it has a level of NOTSET, then all messages will be
88 processed. Otherwise, the root's level will be used as the effective level.
89
Gregory P. Smithc1f079f2012-01-14 12:46:17 -080090 .. versionchanged:: 3.2
91 The *lvl* parameter now accepts a string representation of the
92 level such as 'INFO' as an alternative to the integer constants
93 such as :const:`INFO`.
94
Vinay Sajipc63619b2010-12-19 12:56:57 +000095
96.. method:: Logger.isEnabledFor(lvl)
97
98 Indicates if a message of severity *lvl* would be processed by this logger.
99 This method checks first the module-level level set by
100 ``logging.disable(lvl)`` and then the logger's effective level as determined
101 by :meth:`getEffectiveLevel`.
102
103
104.. method:: Logger.getEffectiveLevel()
105
106 Indicates the effective level for this logger. If a value other than
107 :const:`NOTSET` has been set using :meth:`setLevel`, it is returned. Otherwise,
108 the hierarchy is traversed towards the root until a value other than
109 :const:`NOTSET` is found, and that value is returned.
110
111
112.. method:: Logger.getChild(suffix)
113
114 Returns a logger which is a descendant to this logger, as determined by the suffix.
115 Thus, ``logging.getLogger('abc').getChild('def.ghi')`` would return the same
116 logger as would be returned by ``logging.getLogger('abc.def.ghi')``. This is a
117 convenience method, useful when the parent logger is named using e.g. ``__name__``
118 rather than a literal string.
119
120 .. versionadded:: 3.2
121
122
123.. method:: Logger.debug(msg, *args, **kwargs)
124
125 Logs a message with level :const:`DEBUG` on this logger. The *msg* is the
126 message format string, and the *args* are the arguments which are merged into
127 *msg* using the string formatting operator. (Note that this means that you can
128 use keywords in the format string, together with a single dictionary argument.)
129
130 There are three keyword arguments in *kwargs* which are inspected: *exc_info*
131 which, if it does not evaluate as false, causes exception information to be
132 added to the logging message. If an exception tuple (in the format returned by
133 :func:`sys.exc_info`) is provided, it is used; otherwise, :func:`sys.exc_info`
134 is called to get the exception information.
135
136 The second optional keyword argument is *stack_info*, which defaults to
137 False. If specified as True, stack information is added to the logging
138 message, including the actual logging call. Note that this is not the same
139 stack information as that displayed through specifying *exc_info*: The
140 former is stack frames from the bottom of the stack up to the logging call
141 in the current thread, whereas the latter is information about stack frames
142 which have been unwound, following an exception, while searching for
143 exception handlers.
144
145 You can specify *stack_info* independently of *exc_info*, e.g. to just show
146 how you got to a certain point in your code, even when no exceptions were
147 raised. The stack frames are printed following a header line which says::
148
149 Stack (most recent call last):
150
Éric Araujoa0838232011-11-03 04:35:20 +0100151 This mimics the ``Traceback (most recent call last):`` which is used when
Vinay Sajipc63619b2010-12-19 12:56:57 +0000152 displaying exception frames.
153
154 The third keyword argument is *extra* which can be used to pass a
155 dictionary which is used to populate the __dict__ of the LogRecord created for
156 the logging event with user-defined attributes. These custom attributes can then
157 be used as you like. For example, they could be incorporated into logged
158 messages. For example::
159
160 FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
161 logging.basicConfig(format=FORMAT)
162 d = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
163 logger = logging.getLogger('tcpserver')
164 logger.warning('Protocol problem: %s', 'connection reset', extra=d)
165
166 would print something like ::
167
168 2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset
169
170 The keys in the dictionary passed in *extra* should not clash with the keys used
171 by the logging system. (See the :class:`Formatter` documentation for more
172 information on which keys are used by the logging system.)
173
174 If you choose to use these attributes in logged messages, you need to exercise
175 some care. In the above example, for instance, the :class:`Formatter` has been
176 set up with a format string which expects 'clientip' and 'user' in the attribute
177 dictionary of the LogRecord. If these are missing, the message will not be
178 logged because a string formatting exception will occur. So in this case, you
179 always need to pass the *extra* dictionary with these keys.
180
181 While this might be annoying, this feature is intended for use in specialized
182 circumstances, such as multi-threaded servers where the same code executes in
183 many contexts, and interesting conditions which arise are dependent on this
184 context (such as remote client IP address and authenticated user name, in the
185 above example). In such circumstances, it is likely that specialized
186 :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
187
188 .. versionadded:: 3.2
189 The *stack_info* parameter was added.
190
191
192.. method:: Logger.info(msg, *args, **kwargs)
193
194 Logs a message with level :const:`INFO` on this logger. The arguments are
195 interpreted as for :meth:`debug`.
196
197
198.. method:: Logger.warning(msg, *args, **kwargs)
199
200 Logs a message with level :const:`WARNING` on this logger. The arguments are
201 interpreted as for :meth:`debug`.
202
203
204.. method:: Logger.error(msg, *args, **kwargs)
205
206 Logs a message with level :const:`ERROR` on this logger. The arguments are
207 interpreted as for :meth:`debug`.
208
209
210.. method:: Logger.critical(msg, *args, **kwargs)
211
212 Logs a message with level :const:`CRITICAL` on this logger. The arguments are
213 interpreted as for :meth:`debug`.
214
215
216.. method:: Logger.log(lvl, msg, *args, **kwargs)
217
218 Logs a message with integer level *lvl* on this logger. The other arguments are
219 interpreted as for :meth:`debug`.
220
221
222.. method:: Logger.exception(msg, *args)
223
224 Logs a message with level :const:`ERROR` on this logger. The arguments are
225 interpreted as for :meth:`debug`. Exception info is added to the logging
226 message. This method should only be called from an exception handler.
227
228
229.. method:: Logger.addFilter(filt)
230
231 Adds the specified filter *filt* to this logger.
232
233
234.. method:: Logger.removeFilter(filt)
235
236 Removes the specified filter *filt* from this logger.
237
238
239.. method:: Logger.filter(record)
240
241 Applies this logger's filters to the record and returns a true value if the
242 record is to be processed.
243
244
245.. method:: Logger.addHandler(hdlr)
246
247 Adds the specified handler *hdlr* to this logger.
248
249
250.. method:: Logger.removeHandler(hdlr)
251
252 Removes the specified handler *hdlr* from this logger.
253
254
255.. method:: Logger.findCaller(stack_info=False)
256
257 Finds the caller's source filename and line number. Returns the filename, line
258 number, function name and stack information as a 4-element tuple. The stack
259 information is returned as *None* unless *stack_info* is *True*.
260
261
262.. method:: Logger.handle(record)
263
264 Handles a record by passing it to all handlers associated with this logger and
265 its ancestors (until a false value of *propagate* is found). This method is used
266 for unpickled records received from a socket, as well as those created locally.
267 Logger-level filtering is applied using :meth:`~Logger.filter`.
268
269
270.. method:: Logger.makeRecord(name, lvl, fn, lno, msg, args, exc_info, func=None, extra=None, sinfo=None)
271
272 This is a factory method which can be overridden in subclasses to create
273 specialized :class:`LogRecord` instances.
274
275.. method:: Logger.hasHandlers()
276
277 Checks to see if this logger has any handlers configured. This is done by
278 looking for handlers in this logger and its parents in the logger hierarchy.
279 Returns True if a handler was found, else False. The method stops searching
280 up the hierarchy whenever a logger with the 'propagate' attribute set to
281 False is found - that will be the last logger which is checked for the
282 existence of handlers.
283
284 .. versionadded:: 3.2
285
286
287.. _handler:
288
289Handler Objects
Benjamin Peterson058e31e2009-01-16 03:54:08 +0000290---------------
291
Vinay Sajipc63619b2010-12-19 12:56:57 +0000292Handlers have the following attributes and methods. Note that :class:`Handler`
293is never instantiated directly; this class acts as a base for more useful
294subclasses. However, the :meth:`__init__` method in subclasses needs to call
295:meth:`Handler.__init__`.
Georg Brandl116aa622007-08-15 14:28:22 +0000296
Georg Brandl116aa622007-08-15 14:28:22 +0000297
Vinay Sajipc63619b2010-12-19 12:56:57 +0000298.. method:: Handler.__init__(level=NOTSET)
Georg Brandl116aa622007-08-15 14:28:22 +0000299
Vinay Sajipc63619b2010-12-19 12:56:57 +0000300 Initializes the :class:`Handler` instance by setting its level, setting the list
301 of filters to the empty list and creating a lock (using :meth:`createLock`) for
302 serializing access to an I/O mechanism.
Vinay Sajip30bf1222009-01-10 19:23:34 +0000303
Georg Brandl116aa622007-08-15 14:28:22 +0000304
Vinay Sajipc63619b2010-12-19 12:56:57 +0000305.. method:: Handler.createLock()
Georg Brandl116aa622007-08-15 14:28:22 +0000306
Vinay Sajipc63619b2010-12-19 12:56:57 +0000307 Initializes a thread lock which can be used to serialize access to underlying
308 I/O functionality which may not be threadsafe.
Georg Brandl116aa622007-08-15 14:28:22 +0000309
Georg Brandl116aa622007-08-15 14:28:22 +0000310
Vinay Sajipc63619b2010-12-19 12:56:57 +0000311.. method:: Handler.acquire()
Georg Brandl116aa622007-08-15 14:28:22 +0000312
Vinay Sajipc63619b2010-12-19 12:56:57 +0000313 Acquires the thread lock created with :meth:`createLock`.
Georg Brandl116aa622007-08-15 14:28:22 +0000314
Georg Brandl116aa622007-08-15 14:28:22 +0000315
Vinay Sajipc63619b2010-12-19 12:56:57 +0000316.. method:: Handler.release()
Georg Brandl116aa622007-08-15 14:28:22 +0000317
Vinay Sajipc63619b2010-12-19 12:56:57 +0000318 Releases the thread lock acquired with :meth:`acquire`.
Georg Brandl116aa622007-08-15 14:28:22 +0000319
Georg Brandl116aa622007-08-15 14:28:22 +0000320
Vinay Sajipc63619b2010-12-19 12:56:57 +0000321.. method:: Handler.setLevel(lvl)
Vinay Sajip30bf1222009-01-10 19:23:34 +0000322
Vinay Sajipc63619b2010-12-19 12:56:57 +0000323 Sets the threshold for this handler to *lvl*. Logging messages which are less
324 severe than *lvl* will be ignored. When a handler is created, the level is set
325 to :const:`NOTSET` (which causes all messages to be processed).
326
Gregory P. Smithc1f079f2012-01-14 12:46:17 -0800327 .. versionchanged:: 3.2
328 The *lvl* parameter now accepts a string representation of the
329 level such as 'INFO' as an alternative to the integer constants
330 such as :const:`INFO`.
331
Vinay Sajipc63619b2010-12-19 12:56:57 +0000332
333.. method:: Handler.setFormatter(form)
334
335 Sets the :class:`Formatter` for this handler to *form*.
336
337
338.. method:: Handler.addFilter(filt)
339
340 Adds the specified filter *filt* to this handler.
341
342
343.. method:: Handler.removeFilter(filt)
344
345 Removes the specified filter *filt* from this handler.
346
347
348.. method:: Handler.filter(record)
349
350 Applies this handler's filters to the record and returns a true value if the
351 record is to be processed.
352
353
354.. method:: Handler.flush()
355
356 Ensure all logging output has been flushed. This version does nothing and is
357 intended to be implemented by subclasses.
358
359
360.. method:: Handler.close()
361
362 Tidy up any resources used by the handler. This version does no output but
363 removes the handler from an internal list of handlers which is closed when
364 :func:`shutdown` is called. Subclasses should ensure that this gets called
365 from overridden :meth:`close` methods.
366
367
368.. method:: Handler.handle(record)
369
370 Conditionally emits the specified logging record, depending on filters which may
371 have been added to the handler. Wraps the actual emission of the record with
372 acquisition/release of the I/O thread lock.
373
374
375.. method:: Handler.handleError(record)
376
377 This method should be called from handlers when an exception is encountered
378 during an :meth:`emit` call. By default it does nothing, which means that
379 exceptions get silently ignored. This is what is mostly wanted for a logging
380 system - most users will not care about errors in the logging system, they are
381 more interested in application errors. You could, however, replace this with a
382 custom handler if you wish. The specified record is the one which was being
383 processed when the exception occurred.
384
385
386.. method:: Handler.format(record)
387
388 Do formatting for a record - if a formatter is set, use it. Otherwise, use the
389 default formatter for the module.
390
391
392.. method:: Handler.emit(record)
393
394 Do whatever it takes to actually log the specified logging record. This version
395 is intended to be implemented by subclasses and so raises a
396 :exc:`NotImplementedError`.
397
398For a list of handlers included as standard, see :mod:`logging.handlers`.
399
400.. _formatter-objects:
401
402Formatter Objects
403-----------------
Vinay Sajip121a1c42010-09-08 10:46:15 +0000404
Vinay Sajip30bf1222009-01-10 19:23:34 +0000405.. currentmodule:: logging
406
Vinay Sajipc63619b2010-12-19 12:56:57 +0000407:class:`Formatter` objects have the following attributes and methods. They are
408responsible for converting a :class:`LogRecord` to (usually) a string which can
409be interpreted by either a human or an external system. The base
410:class:`Formatter` allows a formatting string to be specified. If none is
411supplied, the default value of ``'%(message)s'`` is used.
Georg Brandlf9734072008-12-07 15:30:06 +0000412
Vinay Sajipc63619b2010-12-19 12:56:57 +0000413A Formatter can be initialized with a format string which makes use of knowledge
414of the :class:`LogRecord` attributes - such as the default value mentioned above
415making use of the fact that the user's message and arguments are pre-formatted
416into a :class:`LogRecord`'s *message* attribute. This format string contains
417standard Python %-style mapping keys. See section :ref:`old-string-formatting`
418for more information on string formatting.
Georg Brandlf9734072008-12-07 15:30:06 +0000419
Vinay Sajipc63619b2010-12-19 12:56:57 +0000420The useful mapping keys in a :class:`LogRecord` are given in the section on
421:ref:`logrecord-attributes`.
Vinay Sajip121a1c42010-09-08 10:46:15 +0000422
Georg Brandl116aa622007-08-15 14:28:22 +0000423
Vinay Sajipc46102c2011-04-08 01:30:51 +0100424.. class:: Formatter(fmt=None, datefmt=None, style='%')
Georg Brandl116aa622007-08-15 14:28:22 +0000425
Vinay Sajipc63619b2010-12-19 12:56:57 +0000426 Returns a new instance of the :class:`Formatter` class. The instance is
427 initialized with a format string for the message as a whole, as well as a
428 format string for the date/time portion of a message. If no *fmt* is
429 specified, ``'%(message)s'`` is used. If no *datefmt* is specified, the
430 ISO8601 date format is used.
Georg Brandl116aa622007-08-15 14:28:22 +0000431
Vinay Sajipc46102c2011-04-08 01:30:51 +0100432 The *style* parameter can be one of '%', '{' or '$' and determines how
433 the format string will be merged with its data: using one of %-formatting,
Vinay Sajip77f8d292011-04-08 01:34:20 +0100434 :meth:`str.format` or :class:`string.Template`.
Vinay Sajipc46102c2011-04-08 01:30:51 +0100435
436 .. versionchanged:: 3.2
437 The *style* parameter was added.
438
439
Vinay Sajipc63619b2010-12-19 12:56:57 +0000440 .. method:: format(record)
Georg Brandl116aa622007-08-15 14:28:22 +0000441
Vinay Sajipc63619b2010-12-19 12:56:57 +0000442 The record's attribute dictionary is used as the operand to a string
443 formatting operation. Returns the resulting string. Before formatting the
444 dictionary, a couple of preparatory steps are carried out. The *message*
445 attribute of the record is computed using *msg* % *args*. If the
446 formatting string contains ``'(asctime)'``, :meth:`formatTime` is called
447 to format the event time. If there is exception information, it is
448 formatted using :meth:`formatException` and appended to the message. Note
449 that the formatted exception information is cached in attribute
450 *exc_text*. This is useful because the exception information can be
451 pickled and sent across the wire, but you should be careful if you have
452 more than one :class:`Formatter` subclass which customizes the formatting
453 of exception information. In this case, you will have to clear the cached
454 value after a formatter has done its formatting, so that the next
455 formatter to handle the event doesn't use the cached value but
456 recalculates it afresh.
457
458 If stack information is available, it's appended after the exception
459 information, using :meth:`formatStack` to transform it if necessary.
460
461
462 .. method:: formatTime(record, datefmt=None)
463
464 This method should be called from :meth:`format` by a formatter which
465 wants to make use of a formatted time. This method can be overridden in
466 formatters to provide for any specific requirement, but the basic behavior
467 is as follows: if *datefmt* (a string) is specified, it is used with
468 :func:`time.strftime` to format the creation time of the
469 record. Otherwise, the ISO8601 format is used. The resulting string is
470 returned.
471
Vinay Sajipcdc75172011-06-12 11:44:28 +0100472 This function uses a user-configurable function to convert the creation
473 time to a tuple. By default, :func:`time.localtime` is used; to change
474 this for a particular formatter instance, set the ``converter`` attribute
475 to a function with the same signature as :func:`time.localtime` or
476 :func:`time.gmtime`. To change it for all formatters, for example if you
477 want all logging times to be shown in GMT, set the ``converter``
478 attribute in the ``Formatter`` class.
Vinay Sajipc63619b2010-12-19 12:56:57 +0000479
480 .. method:: formatException(exc_info)
481
482 Formats the specified exception information (a standard exception tuple as
483 returned by :func:`sys.exc_info`) as a string. This default implementation
484 just uses :func:`traceback.print_exception`. The resulting string is
485 returned.
486
487 .. method:: formatStack(stack_info)
488
489 Formats the specified stack information (a string as returned by
490 :func:`traceback.print_stack`, but with the last newline removed) as a
491 string. This default implementation just returns the input value.
492
493.. _filter:
494
495Filter Objects
496--------------
497
498``Filters`` can be used by ``Handlers`` and ``Loggers`` for more sophisticated
499filtering than is provided by levels. The base filter class only allows events
500which are below a certain point in the logger hierarchy. For example, a filter
501initialized with 'A.B' will allow events logged by loggers 'A.B', 'A.B.C',
502'A.B.C.D', 'A.B.D' etc. but not 'A.BB', 'B.A.B' etc. If initialized with the
503empty string, all events are passed.
504
505
506.. class:: Filter(name='')
507
508 Returns an instance of the :class:`Filter` class. If *name* is specified, it
509 names a logger which, together with its children, will have its events allowed
510 through the filter. If *name* is the empty string, allows every event.
511
512
513 .. method:: filter(record)
514
515 Is the specified record to be logged? Returns zero for no, nonzero for
516 yes. If deemed appropriate, the record may be modified in-place by this
517 method.
518
519Note that filters attached to handlers are consulted whenever an event is
520emitted by the handler, whereas filters attached to loggers are consulted
521whenever an event is logged to the handler (using :meth:`debug`, :meth:`info`,
522etc.) This means that events which have been generated by descendant loggers
523will not be filtered by a logger's filter setting, unless the filter has also
524been applied to those descendant loggers.
525
526You don't actually need to subclass ``Filter``: you can pass any instance
527which has a ``filter`` method with the same semantics.
528
529.. versionchanged:: 3.2
530 You don't need to create specialized ``Filter`` classes, or use other
531 classes with a ``filter`` method: you can use a function (or other
532 callable) as a filter. The filtering logic will check to see if the filter
533 object has a ``filter`` attribute: if it does, it's assumed to be a
534 ``Filter`` and its :meth:`~Filter.filter` method is called. Otherwise, it's
535 assumed to be a callable and called with the record as the single
536 parameter. The returned value should conform to that returned by
537 :meth:`~Filter.filter`.
538
539Although filters are used primarily to filter records based on more
540sophisticated criteria than levels, they get to see every record which is
541processed by the handler or logger they're attached to: this can be useful if
542you want to do things like counting how many records were processed by a
543particular logger or handler, or adding, changing or removing attributes in
544the LogRecord being processed. Obviously changing the LogRecord needs to be
545done with some care, but it does allow the injection of contextual information
546into logs (see :ref:`filters-contextual`).
547
548.. _log-record:
549
550LogRecord Objects
551-----------------
552
553:class:`LogRecord` instances are created automatically by the :class:`Logger`
554every time something is logged, and can be created manually via
555:func:`makeLogRecord` (for example, from a pickled event received over the
556wire).
557
558
559.. class:: LogRecord(name, level, pathname, lineno, msg, args, exc_info, func=None, sinfo=None)
560
561 Contains all the information pertinent to the event being logged.
562
563 The primary information is passed in :attr:`msg` and :attr:`args`, which
564 are combined using ``msg % args`` to create the :attr:`message` field of the
565 record.
566
567 :param name: The name of the logger used to log the event represented by
568 this LogRecord.
569 :param level: The numeric level of the logging event (one of DEBUG, INFO etc.)
Vinay Sajip0aaa9e12011-06-11 23:03:37 +0100570 Note that this is converted to *two* attributes of the LogRecord:
571 ``levelno`` for the numeric value and ``levelname`` for the
572 corresponding level name.
Vinay Sajipc63619b2010-12-19 12:56:57 +0000573 :param pathname: The full pathname of the source file where the logging call
574 was made.
575 :param lineno: The line number in the source file where the logging call was
576 made.
577 :param msg: The event description message, possibly a format string with
578 placeholders for variable data.
579 :param args: Variable data to merge into the *msg* argument to obtain the
580 event description.
581 :param exc_info: An exception tuple with the current exception information,
582 or *None* if no exception information is available.
583 :param func: The name of the function or method from which the logging call
584 was invoked.
585 :param sinfo: A text string representing stack information from the base of
586 the stack in the current thread, up to the logging call.
587
588 .. method:: getMessage()
589
590 Returns the message for this :class:`LogRecord` instance after merging any
591 user-supplied arguments with the message. If the user-supplied message
592 argument to the logging call is not a string, :func:`str` is called on it to
593 convert it to a string. This allows use of user-defined classes as
594 messages, whose ``__str__`` method can return the actual format string to
595 be used.
596
597 .. versionchanged:: 3.2
598 The creation of a ``LogRecord`` has been made more configurable by
599 providing a factory which is used to create the record. The factory can be
600 set using :func:`getLogRecordFactory` and :func:`setLogRecordFactory`
601 (see this for the factory's signature).
602
603 This functionality can be used to inject your own values into a
604 LogRecord at creation time. You can use the following pattern::
605
606 old_factory = logging.getLogRecordFactory()
607
608 def record_factory(*args, **kwargs):
609 record = old_factory(*args, **kwargs)
610 record.custom_attribute = 0xdecafbad
611 return record
612
613 logging.setLogRecordFactory(record_factory)
614
615 With this pattern, multiple factories could be chained, and as long
616 as they don't overwrite each other's attributes or unintentionally
617 overwrite the standard attributes listed above, there should be no
618 surprises.
619
620
621.. _logrecord-attributes:
622
623LogRecord attributes
624--------------------
625
626The LogRecord has a number of attributes, most of which are derived from the
627parameters to the constructor. (Note that the names do not always correspond
628exactly between the LogRecord constructor parameters and the LogRecord
629attributes.) These attributes can be used to merge data from the record into
630the format string. The following table lists (in alphabetical order) the
631attribute names, their meanings and the corresponding placeholder in a %-style
632format string.
633
634If you are using {}-formatting (:func:`str.format`), you can use
635``{attrname}`` as the placeholder in the format string. If you are using
636$-formatting (:class:`string.Template`), use the form ``${attrname}``. In
637both cases, of course, replace ``attrname`` with the actual attribute name
638you want to use.
639
640In the case of {}-formatting, you can specify formatting flags by placing them
641after the attribute name, separated from it with a colon. For example: a
642placeholder of ``{msecs:03d}`` would format a millisecond value of ``4`` as
643``004``. Refer to the :meth:`str.format` documentation for full details on
644the options available to you.
645
646+----------------+-------------------------+-----------------------------------------------+
647| Attribute name | Format | Description |
648+================+=========================+===============================================+
649| args | You shouldn't need to | The tuple of arguments merged into ``msg`` to |
650| | format this yourself. | produce ``message``. |
651+----------------+-------------------------+-----------------------------------------------+
652| asctime | ``%(asctime)s`` | Human-readable time when the |
653| | | :class:`LogRecord` was created. By default |
654| | | this is of the form '2003-07-08 16:49:45,896' |
655| | | (the numbers after the comma are millisecond |
656| | | portion of the time). |
657+----------------+-------------------------+-----------------------------------------------+
658| created | ``%(created)f`` | Time when the :class:`LogRecord` was created |
659| | | (as returned by :func:`time.time`). |
660+----------------+-------------------------+-----------------------------------------------+
661| exc_info | You shouldn't need to | Exception tuple (à la ``sys.exc_info``) or, |
662| | format this yourself. | if no exception has occurred, *None*. |
663+----------------+-------------------------+-----------------------------------------------+
664| filename | ``%(filename)s`` | Filename portion of ``pathname``. |
665+----------------+-------------------------+-----------------------------------------------+
666| funcName | ``%(funcName)s`` | Name of function containing the logging call. |
667+----------------+-------------------------+-----------------------------------------------+
668| levelname | ``%(levelname)s`` | Text logging level for the message |
669| | | (``'DEBUG'``, ``'INFO'``, ``'WARNING'``, |
670| | | ``'ERROR'``, ``'CRITICAL'``). |
671+----------------+-------------------------+-----------------------------------------------+
672| levelno | ``%(levelno)s`` | Numeric logging level for the message |
673| | | (:const:`DEBUG`, :const:`INFO`, |
674| | | :const:`WARNING`, :const:`ERROR`, |
675| | | :const:`CRITICAL`). |
676+----------------+-------------------------+-----------------------------------------------+
677| lineno | ``%(lineno)d`` | Source line number where the logging call was |
678| | | issued (if available). |
679+----------------+-------------------------+-----------------------------------------------+
680| module | ``%(module)s`` | Module (name portion of ``filename``). |
681+----------------+-------------------------+-----------------------------------------------+
682| msecs | ``%(msecs)d`` | Millisecond portion of the time when the |
683| | | :class:`LogRecord` was created. |
684+----------------+-------------------------+-----------------------------------------------+
685| message | ``%(message)s`` | The logged message, computed as ``msg % |
686| | | args``. This is set when |
687| | | :meth:`Formatter.format` is invoked. |
688+----------------+-------------------------+-----------------------------------------------+
689| msg | You shouldn't need to | The format string passed in the original |
690| | format this yourself. | logging call. Merged with ``args`` to |
691| | | produce ``message``, or an arbitrary object |
692| | | (see :ref:`arbitrary-object-messages`). |
693+----------------+-------------------------+-----------------------------------------------+
694| name | ``%(name)s`` | Name of the logger used to log the call. |
695+----------------+-------------------------+-----------------------------------------------+
696| pathname | ``%(pathname)s`` | Full pathname of the source file where the |
697| | | logging call was issued (if available). |
698+----------------+-------------------------+-----------------------------------------------+
699| process | ``%(process)d`` | Process ID (if available). |
700+----------------+-------------------------+-----------------------------------------------+
701| processName | ``%(processName)s`` | Process name (if available). |
702+----------------+-------------------------+-----------------------------------------------+
703| relativeCreated| ``%(relativeCreated)d`` | Time in milliseconds when the LogRecord was |
704| | | created, relative to the time the logging |
705| | | module was loaded. |
706+----------------+-------------------------+-----------------------------------------------+
707| stack_info | You shouldn't need to | Stack frame information (where available) |
708| | format this yourself. | from the bottom of the stack in the current |
709| | | thread, up to and including the stack frame |
710| | | of the logging call which resulted in the |
711| | | creation of this record. |
712+----------------+-------------------------+-----------------------------------------------+
713| thread | ``%(thread)d`` | Thread ID (if available). |
714+----------------+-------------------------+-----------------------------------------------+
715| threadName | ``%(threadName)s`` | Thread name (if available). |
716+----------------+-------------------------+-----------------------------------------------+
717
718
719.. _logger-adapter:
720
721LoggerAdapter Objects
722---------------------
723
724:class:`LoggerAdapter` instances are used to conveniently pass contextual
725information into logging calls. For a usage example , see the section on
726:ref:`adding contextual information to your logging output <context-info>`.
727
Vinay Sajipc63619b2010-12-19 12:56:57 +0000728.. class:: LoggerAdapter(logger, extra)
729
730 Returns an instance of :class:`LoggerAdapter` initialized with an
731 underlying :class:`Logger` instance and a dict-like object.
732
733 .. method:: process(msg, kwargs)
734
735 Modifies the message and/or keyword arguments passed to a logging call in
736 order to insert contextual information. This implementation takes the object
737 passed as *extra* to the constructor and adds it to *kwargs* using key
738 'extra'. The return value is a (*msg*, *kwargs*) tuple which has the
739 (possibly modified) versions of the arguments passed in.
740
741In addition to the above, :class:`LoggerAdapter` supports the following
742methods of :class:`Logger`, i.e. :meth:`debug`, :meth:`info`, :meth:`warning`,
743:meth:`error`, :meth:`exception`, :meth:`critical`, :meth:`log`,
744:meth:`isEnabledFor`, :meth:`getEffectiveLevel`, :meth:`setLevel`,
745:meth:`hasHandlers`. These methods have the same signatures as their
746counterparts in :class:`Logger`, so you can use the two types of instances
747interchangeably.
748
749.. versionchanged:: 3.2
750 The :meth:`isEnabledFor`, :meth:`getEffectiveLevel`, :meth:`setLevel` and
751 :meth:`hasHandlers` methods were added to :class:`LoggerAdapter`. These
752 methods delegate to the underlying logger.
753
754
755Thread Safety
756-------------
757
758The logging module is intended to be thread-safe without any special work
759needing to be done by its clients. It achieves this though using threading
760locks; there is one lock to serialize access to the module's shared data, and
761each handler also creates a lock to serialize access to its underlying I/O.
762
763If you are implementing asynchronous signal handlers using the :mod:`signal`
764module, you may not be able to use logging from within such handlers. This is
765because lock implementations in the :mod:`threading` module are not always
766re-entrant, and so cannot be invoked from such signal handlers.
767
Georg Brandl116aa622007-08-15 14:28:22 +0000768
Benjamin Peterson058e31e2009-01-16 03:54:08 +0000769Module-Level Functions
770----------------------
771
Georg Brandl116aa622007-08-15 14:28:22 +0000772In addition to the classes described above, there are a number of module- level
773functions.
774
775
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000776.. function:: getLogger(name=None)
Georg Brandl116aa622007-08-15 14:28:22 +0000777
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000778 Return a logger with the specified name or, if name is ``None``, return a
Georg Brandl116aa622007-08-15 14:28:22 +0000779 logger which is the root logger of the hierarchy. If specified, the name is
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000780 typically a dot-separated hierarchical name like *'a'*, *'a.b'* or *'a.b.c.d'*.
Georg Brandl116aa622007-08-15 14:28:22 +0000781 Choice of these names is entirely up to the developer who is using logging.
782
783 All calls to this function with a given name return the same logger instance.
784 This means that logger instances never need to be passed between different parts
785 of an application.
786
787
788.. function:: getLoggerClass()
789
790 Return either the standard :class:`Logger` class, or the last class passed to
791 :func:`setLoggerClass`. This function may be called from within a new class
792 definition, to ensure that installing a customised :class:`Logger` class will
793 not undo customisations already applied by other code. For example::
794
795 class MyLogger(logging.getLoggerClass()):
796 # ... override behaviour here
797
798
Vinay Sajip61561522010-12-03 11:50:38 +0000799.. function:: getLogRecordFactory()
800
801 Return a callable which is used to create a :class:`LogRecord`.
802
803 .. versionadded:: 3.2
Vinay Sajip61561522010-12-03 11:50:38 +0000804 This function has been provided, along with :func:`setLogRecordFactory`,
805 to allow developers more control over how the :class:`LogRecord`
806 representing a logging event is constructed.
807
808 See :func:`setLogRecordFactory` for more information about the how the
809 factory is called.
810
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000811.. function:: debug(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000812
813 Logs a message with level :const:`DEBUG` on the root logger. The *msg* is the
814 message format string, and the *args* are the arguments which are merged into
815 *msg* using the string formatting operator. (Note that this means that you can
816 use keywords in the format string, together with a single dictionary argument.)
817
Vinay Sajip8593ae62010-11-14 21:33:04 +0000818 There are three keyword arguments in *kwargs* which are inspected: *exc_info*
Georg Brandl116aa622007-08-15 14:28:22 +0000819 which, if it does not evaluate as false, causes exception information to be
820 added to the logging message. If an exception tuple (in the format returned by
821 :func:`sys.exc_info`) is provided, it is used; otherwise, :func:`sys.exc_info`
822 is called to get the exception information.
823
Vinay Sajip8593ae62010-11-14 21:33:04 +0000824 The second optional keyword argument is *stack_info*, which defaults to
825 False. If specified as True, stack information is added to the logging
826 message, including the actual logging call. Note that this is not the same
827 stack information as that displayed through specifying *exc_info*: The
828 former is stack frames from the bottom of the stack up to the logging call
829 in the current thread, whereas the latter is information about stack frames
830 which have been unwound, following an exception, while searching for
831 exception handlers.
832
833 You can specify *stack_info* independently of *exc_info*, e.g. to just show
834 how you got to a certain point in your code, even when no exceptions were
835 raised. The stack frames are printed following a header line which says::
836
837 Stack (most recent call last):
838
Éric Araujoa0838232011-11-03 04:35:20 +0100839 This mimics the ``Traceback (most recent call last):`` which is used when
Vinay Sajip8593ae62010-11-14 21:33:04 +0000840 displaying exception frames.
841
842 The third optional keyword argument is *extra* which can be used to pass a
Georg Brandl116aa622007-08-15 14:28:22 +0000843 dictionary which is used to populate the __dict__ of the LogRecord created for
844 the logging event with user-defined attributes. These custom attributes can then
845 be used as you like. For example, they could be incorporated into logged
846 messages. For example::
847
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000848 FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
Georg Brandl116aa622007-08-15 14:28:22 +0000849 logging.basicConfig(format=FORMAT)
850 d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000851 logging.warning('Protocol problem: %s', 'connection reset', extra=d)
Georg Brandl116aa622007-08-15 14:28:22 +0000852
Vinay Sajip4039aff2010-09-11 10:25:28 +0000853 would print something like::
Georg Brandl116aa622007-08-15 14:28:22 +0000854
855 2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset
856
857 The keys in the dictionary passed in *extra* should not clash with the keys used
858 by the logging system. (See the :class:`Formatter` documentation for more
859 information on which keys are used by the logging system.)
860
861 If you choose to use these attributes in logged messages, you need to exercise
862 some care. In the above example, for instance, the :class:`Formatter` has been
863 set up with a format string which expects 'clientip' and 'user' in the attribute
864 dictionary of the LogRecord. If these are missing, the message will not be
865 logged because a string formatting exception will occur. So in this case, you
866 always need to pass the *extra* dictionary with these keys.
867
868 While this might be annoying, this feature is intended for use in specialized
869 circumstances, such as multi-threaded servers where the same code executes in
870 many contexts, and interesting conditions which arise are dependent on this
871 context (such as remote client IP address and authenticated user name, in the
872 above example). In such circumstances, it is likely that specialized
873 :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
874
Vinay Sajip8593ae62010-11-14 21:33:04 +0000875 .. versionadded:: 3.2
876 The *stack_info* parameter was added.
Georg Brandl116aa622007-08-15 14:28:22 +0000877
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000878.. function:: info(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000879
880 Logs a message with level :const:`INFO` on the root logger. The arguments are
881 interpreted as for :func:`debug`.
882
883
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000884.. function:: warning(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000885
886 Logs a message with level :const:`WARNING` on the root logger. The arguments are
887 interpreted as for :func:`debug`.
888
889
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000890.. function:: error(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000891
892 Logs a message with level :const:`ERROR` on the root logger. The arguments are
893 interpreted as for :func:`debug`.
894
895
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000896.. function:: critical(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000897
898 Logs a message with level :const:`CRITICAL` on the root logger. The arguments
899 are interpreted as for :func:`debug`.
900
901
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000902.. function:: exception(msg, *args)
Georg Brandl116aa622007-08-15 14:28:22 +0000903
904 Logs a message with level :const:`ERROR` on the root logger. The arguments are
905 interpreted as for :func:`debug`. Exception info is added to the logging
906 message. This function should only be called from an exception handler.
907
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000908.. function:: log(level, msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000909
910 Logs a message with level *level* on the root logger. The other arguments are
911 interpreted as for :func:`debug`.
912
Vinay Sajipc8c8c692010-09-17 10:09:04 +0000913 PLEASE NOTE: The above module-level functions which delegate to the root
914 logger should *not* be used in threads, in versions of Python earlier than
915 2.7.1 and 3.2, unless at least one handler has been added to the root
916 logger *before* the threads are started. These convenience functions call
917 :func:`basicConfig` to ensure that at least one handler is available; in
918 earlier versions of Python, this can (under rare circumstances) lead to
919 handlers being added multiple times to the root logger, which can in turn
920 lead to multiple messages for the same event.
Georg Brandl116aa622007-08-15 14:28:22 +0000921
922.. function:: disable(lvl)
923
924 Provides an overriding level *lvl* for all loggers which takes precedence over
925 the logger's own level. When the need arises to temporarily throttle logging
Benjamin Peterson886af962010-03-21 23:13:07 +0000926 output down across the whole application, this function can be useful. Its
927 effect is to disable all logging calls of severity *lvl* and below, so that
928 if you call it with a value of INFO, then all INFO and DEBUG events would be
929 discarded, whereas those of severity WARNING and above would be processed
930 according to the logger's effective level.
Georg Brandl116aa622007-08-15 14:28:22 +0000931
932
933.. function:: addLevelName(lvl, levelName)
934
935 Associates level *lvl* with text *levelName* in an internal dictionary, which is
936 used to map numeric levels to a textual representation, for example when a
937 :class:`Formatter` formats a message. This function can also be used to define
938 your own levels. The only constraints are that all levels used must be
939 registered using this function, levels should be positive integers and they
940 should increase in increasing order of severity.
941
Vinay Sajipc8c8c692010-09-17 10:09:04 +0000942 NOTE: If you are thinking of defining your own levels, please see the section
943 on :ref:`custom-levels`.
Georg Brandl116aa622007-08-15 14:28:22 +0000944
945.. function:: getLevelName(lvl)
946
947 Returns the textual representation of logging level *lvl*. If the level is one
948 of the predefined levels :const:`CRITICAL`, :const:`ERROR`, :const:`WARNING`,
949 :const:`INFO` or :const:`DEBUG` then you get the corresponding string. If you
950 have associated levels with names using :func:`addLevelName` then the name you
951 have associated with *lvl* is returned. If a numeric value corresponding to one
952 of the defined levels is passed in, the corresponding string representation is
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000953 returned. Otherwise, the string 'Level %s' % lvl is returned.
Georg Brandl116aa622007-08-15 14:28:22 +0000954
955
956.. function:: makeLogRecord(attrdict)
957
958 Creates and returns a new :class:`LogRecord` instance whose attributes are
959 defined by *attrdict*. This function is useful for taking a pickled
960 :class:`LogRecord` attribute dictionary, sent over a socket, and reconstituting
961 it as a :class:`LogRecord` instance at the receiving end.
962
963
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000964.. function:: basicConfig(**kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000965
966 Does basic configuration for the logging system by creating a
967 :class:`StreamHandler` with a default :class:`Formatter` and adding it to the
Vinay Sajipcbabd7e2009-10-10 20:32:36 +0000968 root logger. The functions :func:`debug`, :func:`info`, :func:`warning`,
Georg Brandl116aa622007-08-15 14:28:22 +0000969 :func:`error` and :func:`critical` will call :func:`basicConfig` automatically
970 if no handlers are defined for the root logger.
971
Vinay Sajipcbabd7e2009-10-10 20:32:36 +0000972 This function does nothing if the root logger already has handlers
973 configured for it.
974
Vinay Sajipc8c8c692010-09-17 10:09:04 +0000975 PLEASE NOTE: This function should be called from the main thread
976 before other threads are started. In versions of Python prior to
977 2.7.1 and 3.2, if this function is called from multiple threads,
978 it is possible (in rare circumstances) that a handler will be added
979 to the root logger more than once, leading to unexpected results
980 such as messages being duplicated in the log.
981
Georg Brandl116aa622007-08-15 14:28:22 +0000982 The following keyword arguments are supported.
983
984 +--------------+---------------------------------------------+
985 | Format | Description |
986 +==============+=============================================+
987 | ``filename`` | Specifies that a FileHandler be created, |
988 | | using the specified filename, rather than a |
989 | | StreamHandler. |
990 +--------------+---------------------------------------------+
991 | ``filemode`` | Specifies the mode to open the file, if |
992 | | filename is specified (if filemode is |
993 | | unspecified, it defaults to 'a'). |
994 +--------------+---------------------------------------------+
995 | ``format`` | Use the specified format string for the |
996 | | handler. |
997 +--------------+---------------------------------------------+
998 | ``datefmt`` | Use the specified date/time format. |
999 +--------------+---------------------------------------------+
Vinay Sajipc5b27302010-10-31 14:59:16 +00001000 | ``style`` | If ``format`` is specified, use this style |
1001 | | for the format string. One of '%', '{' or |
1002 | | '$' for %-formatting, :meth:`str.format` or |
1003 | | :class:`string.Template` respectively, and |
1004 | | defaulting to '%' if not specified. |
1005 +--------------+---------------------------------------------+
Georg Brandl116aa622007-08-15 14:28:22 +00001006 | ``level`` | Set the root logger level to the specified |
1007 | | level. |
1008 +--------------+---------------------------------------------+
1009 | ``stream`` | Use the specified stream to initialize the |
1010 | | StreamHandler. Note that this argument is |
1011 | | incompatible with 'filename' - if both are |
1012 | | present, 'stream' is ignored. |
1013 +--------------+---------------------------------------------+
1014
Vinay Sajipc5b27302010-10-31 14:59:16 +00001015 .. versionchanged:: 3.2
1016 The ``style`` argument was added.
1017
1018
Georg Brandl116aa622007-08-15 14:28:22 +00001019.. function:: shutdown()
1020
1021 Informs the logging system to perform an orderly shutdown by flushing and
Christian Heimesb186d002008-03-18 15:15:01 +00001022 closing all handlers. This should be called at application exit and no
1023 further use of the logging system should be made after this call.
Georg Brandl116aa622007-08-15 14:28:22 +00001024
1025
1026.. function:: setLoggerClass(klass)
1027
1028 Tells the logging system to use the class *klass* when instantiating a logger.
1029 The class should define :meth:`__init__` such that only a name argument is
1030 required, and the :meth:`__init__` should call :meth:`Logger.__init__`. This
1031 function is typically called before any loggers are instantiated by applications
1032 which need to use custom logger behavior.
1033
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001034
Vinay Sajip61561522010-12-03 11:50:38 +00001035.. function:: setLogRecordFactory(factory)
1036
1037 Set a callable which is used to create a :class:`LogRecord`.
1038
1039 :param factory: The factory callable to be used to instantiate a log record.
1040
1041 .. versionadded:: 3.2
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001042 This function has been provided, along with :func:`getLogRecordFactory`, to
1043 allow developers more control over how the :class:`LogRecord` representing
1044 a logging event is constructed.
Vinay Sajip61561522010-12-03 11:50:38 +00001045
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001046 The factory has the following signature:
Vinay Sajip61561522010-12-03 11:50:38 +00001047
Vinay Sajip9a6b4002010-12-14 19:40:21 +00001048 ``factory(name, level, fn, lno, msg, args, exc_info, func=None, sinfo=None, **kwargs)``
Vinay Sajip61561522010-12-03 11:50:38 +00001049
1050 :name: The logger name.
1051 :level: The logging level (numeric).
1052 :fn: The full pathname of the file where the logging call was made.
1053 :lno: The line number in the file where the logging call was made.
1054 :msg: The logging message.
1055 :args: The arguments for the logging message.
1056 :exc_info: An exception tuple, or None.
1057 :func: The name of the function or method which invoked the logging
1058 call.
1059 :sinfo: A stack traceback such as is provided by
1060 :func:`traceback.print_stack`, showing the call hierarchy.
1061 :kwargs: Additional keyword arguments.
Georg Brandl116aa622007-08-15 14:28:22 +00001062
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001063
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001064Integration with the warnings module
1065------------------------------------
1066
1067The :func:`captureWarnings` function can be used to integrate :mod:`logging`
1068with the :mod:`warnings` module.
1069
1070.. function:: captureWarnings(capture)
1071
1072 This function is used to turn the capture of warnings by logging on and
1073 off.
1074
Senthil Kumaran46a48be2010-10-15 13:10:10 +00001075 If *capture* is ``True``, warnings issued by the :mod:`warnings` module will
1076 be redirected to the logging system. Specifically, a warning will be
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001077 formatted using :func:`warnings.formatwarning` and the resulting string
Éric Araujoa0838232011-11-03 04:35:20 +01001078 logged to a logger named ``'py.warnings'`` with a severity of ``'WARNING'``.
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001079
Senthil Kumaran46a48be2010-10-15 13:10:10 +00001080 If *capture* is ``False``, the redirection of warnings to the logging system
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001081 will stop, and warnings will be redirected to their original destinations
Éric Araujoa0838232011-11-03 04:35:20 +01001082 (i.e. those in effect before ``captureWarnings(True)`` was called).
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001083
1084
Vinay Sajipc63619b2010-12-19 12:56:57 +00001085.. seealso::
Vinay Sajip75043022010-12-19 06:02:31 +00001086
Vinay Sajipc63619b2010-12-19 12:56:57 +00001087 Module :mod:`logging.config`
1088 Configuration API for the logging module.
Georg Brandl116aa622007-08-15 14:28:22 +00001089
Vinay Sajipc63619b2010-12-19 12:56:57 +00001090 Module :mod:`logging.handlers`
1091 Useful handlers included with the logging module.
Georg Brandl116aa622007-08-15 14:28:22 +00001092
Vinay Sajipc63619b2010-12-19 12:56:57 +00001093 :pep:`282` - A Logging System
1094 The proposal which described this feature for inclusion in the Python standard
1095 library.
Georg Brandl116aa622007-08-15 14:28:22 +00001096
Vinay Sajipc63619b2010-12-19 12:56:57 +00001097 `Original Python logging package <http://www.red-dove.com/python_logging.html>`_
1098 This is the original source for the :mod:`logging` package. The version of the
1099 package available from this site is suitable for use with Python 1.5.2, 2.1.x
1100 and 2.2.x, which do not include the :mod:`logging` package in the standard
1101 library.
Christian Heimes8b0facf2007-12-04 19:30:01 +00001102