blob: 32f762d5068fbcf190a0f5b12fb995ecce068ce7 [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 Sajipc63619b2010-12-19 12:56:57 +000060 If this evaluates to false, logging messages are not passed by this logger or by
61 its child loggers to the handlers of higher level (ancestor) loggers. The
62 constructor sets this attribute to 1.
Vinay Sajipc8c8c692010-09-17 10:09:04 +000063
64
Vinay Sajipc63619b2010-12-19 12:56:57 +000065.. method:: Logger.setLevel(lvl)
Vinay Sajipf234eb92010-12-12 17:37:27 +000066
Vinay Sajipc63619b2010-12-19 12:56:57 +000067 Sets the threshold for this logger to *lvl*. Logging messages which are less
68 severe than *lvl* will be ignored. When a logger is created, the level is set to
69 :const:`NOTSET` (which causes all messages to be processed when the logger is
70 the root logger, or delegation to the parent when the logger is a non-root
71 logger). Note that the root logger is created with level :const:`WARNING`.
72
73 The term 'delegation to the parent' means that if a logger has a level of
74 NOTSET, its chain of ancestor loggers is traversed until either an ancestor with
75 a level other than NOTSET is found, or the root is reached.
76
77 If an ancestor is found with a level other than NOTSET, then that ancestor's
78 level is treated as the effective level of the logger where the ancestor search
79 began, and is used to determine how a logging event is handled.
80
81 If the root is reached, and it has a level of NOTSET, then all messages will be
82 processed. Otherwise, the root's level will be used as the effective level.
83
84
85.. method:: Logger.isEnabledFor(lvl)
86
87 Indicates if a message of severity *lvl* would be processed by this logger.
88 This method checks first the module-level level set by
89 ``logging.disable(lvl)`` and then the logger's effective level as determined
90 by :meth:`getEffectiveLevel`.
91
92
93.. method:: Logger.getEffectiveLevel()
94
95 Indicates the effective level for this logger. If a value other than
96 :const:`NOTSET` has been set using :meth:`setLevel`, it is returned. Otherwise,
97 the hierarchy is traversed towards the root until a value other than
98 :const:`NOTSET` is found, and that value is returned.
99
100
101.. method:: Logger.getChild(suffix)
102
103 Returns a logger which is a descendant to this logger, as determined by the suffix.
104 Thus, ``logging.getLogger('abc').getChild('def.ghi')`` would return the same
105 logger as would be returned by ``logging.getLogger('abc.def.ghi')``. This is a
106 convenience method, useful when the parent logger is named using e.g. ``__name__``
107 rather than a literal string.
108
109 .. versionadded:: 3.2
110
111
112.. method:: Logger.debug(msg, *args, **kwargs)
113
114 Logs a message with level :const:`DEBUG` on this logger. The *msg* is the
115 message format string, and the *args* are the arguments which are merged into
116 *msg* using the string formatting operator. (Note that this means that you can
117 use keywords in the format string, together with a single dictionary argument.)
118
119 There are three keyword arguments in *kwargs* which are inspected: *exc_info*
120 which, if it does not evaluate as false, causes exception information to be
121 added to the logging message. If an exception tuple (in the format returned by
122 :func:`sys.exc_info`) is provided, it is used; otherwise, :func:`sys.exc_info`
123 is called to get the exception information.
124
125 The second optional keyword argument is *stack_info*, which defaults to
126 False. If specified as True, stack information is added to the logging
127 message, including the actual logging call. Note that this is not the same
128 stack information as that displayed through specifying *exc_info*: The
129 former is stack frames from the bottom of the stack up to the logging call
130 in the current thread, whereas the latter is information about stack frames
131 which have been unwound, following an exception, while searching for
132 exception handlers.
133
134 You can specify *stack_info* independently of *exc_info*, e.g. to just show
135 how you got to a certain point in your code, even when no exceptions were
136 raised. The stack frames are printed following a header line which says::
137
138 Stack (most recent call last):
139
140 This mimics the `Traceback (most recent call last):` which is used when
141 displaying exception frames.
142
143 The third keyword argument is *extra* which can be used to pass a
144 dictionary which is used to populate the __dict__ of the LogRecord created for
145 the logging event with user-defined attributes. These custom attributes can then
146 be used as you like. For example, they could be incorporated into logged
147 messages. For example::
148
149 FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
150 logging.basicConfig(format=FORMAT)
151 d = { 'clientip' : '192.168.0.1', 'user' : 'fbloggs' }
152 logger = logging.getLogger('tcpserver')
153 logger.warning('Protocol problem: %s', 'connection reset', extra=d)
154
155 would print something like ::
156
157 2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset
158
159 The keys in the dictionary passed in *extra* should not clash with the keys used
160 by the logging system. (See the :class:`Formatter` documentation for more
161 information on which keys are used by the logging system.)
162
163 If you choose to use these attributes in logged messages, you need to exercise
164 some care. In the above example, for instance, the :class:`Formatter` has been
165 set up with a format string which expects 'clientip' and 'user' in the attribute
166 dictionary of the LogRecord. If these are missing, the message will not be
167 logged because a string formatting exception will occur. So in this case, you
168 always need to pass the *extra* dictionary with these keys.
169
170 While this might be annoying, this feature is intended for use in specialized
171 circumstances, such as multi-threaded servers where the same code executes in
172 many contexts, and interesting conditions which arise are dependent on this
173 context (such as remote client IP address and authenticated user name, in the
174 above example). In such circumstances, it is likely that specialized
175 :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
176
177 .. versionadded:: 3.2
178 The *stack_info* parameter was added.
179
180
181.. method:: Logger.info(msg, *args, **kwargs)
182
183 Logs a message with level :const:`INFO` on this logger. The arguments are
184 interpreted as for :meth:`debug`.
185
186
187.. method:: Logger.warning(msg, *args, **kwargs)
188
189 Logs a message with level :const:`WARNING` on this logger. The arguments are
190 interpreted as for :meth:`debug`.
191
192
193.. method:: Logger.error(msg, *args, **kwargs)
194
195 Logs a message with level :const:`ERROR` on this logger. The arguments are
196 interpreted as for :meth:`debug`.
197
198
199.. method:: Logger.critical(msg, *args, **kwargs)
200
201 Logs a message with level :const:`CRITICAL` on this logger. The arguments are
202 interpreted as for :meth:`debug`.
203
204
205.. method:: Logger.log(lvl, msg, *args, **kwargs)
206
207 Logs a message with integer level *lvl* on this logger. The other arguments are
208 interpreted as for :meth:`debug`.
209
210
211.. method:: Logger.exception(msg, *args)
212
213 Logs a message with level :const:`ERROR` on this logger. The arguments are
214 interpreted as for :meth:`debug`. Exception info is added to the logging
215 message. This method should only be called from an exception handler.
216
217
218.. method:: Logger.addFilter(filt)
219
220 Adds the specified filter *filt* to this logger.
221
222
223.. method:: Logger.removeFilter(filt)
224
225 Removes the specified filter *filt* from this logger.
226
227
228.. method:: Logger.filter(record)
229
230 Applies this logger's filters to the record and returns a true value if the
231 record is to be processed.
232
233
234.. method:: Logger.addHandler(hdlr)
235
236 Adds the specified handler *hdlr* to this logger.
237
238
239.. method:: Logger.removeHandler(hdlr)
240
241 Removes the specified handler *hdlr* from this logger.
242
243
244.. method:: Logger.findCaller(stack_info=False)
245
246 Finds the caller's source filename and line number. Returns the filename, line
247 number, function name and stack information as a 4-element tuple. The stack
248 information is returned as *None* unless *stack_info* is *True*.
249
250
251.. method:: Logger.handle(record)
252
253 Handles a record by passing it to all handlers associated with this logger and
254 its ancestors (until a false value of *propagate* is found). This method is used
255 for unpickled records received from a socket, as well as those created locally.
256 Logger-level filtering is applied using :meth:`~Logger.filter`.
257
258
259.. method:: Logger.makeRecord(name, lvl, fn, lno, msg, args, exc_info, func=None, extra=None, sinfo=None)
260
261 This is a factory method which can be overridden in subclasses to create
262 specialized :class:`LogRecord` instances.
263
264.. method:: Logger.hasHandlers()
265
266 Checks to see if this logger has any handlers configured. This is done by
267 looking for handlers in this logger and its parents in the logger hierarchy.
268 Returns True if a handler was found, else False. The method stops searching
269 up the hierarchy whenever a logger with the 'propagate' attribute set to
270 False is found - that will be the last logger which is checked for the
271 existence of handlers.
272
273 .. versionadded:: 3.2
274
275
276.. _handler:
277
278Handler Objects
Benjamin Peterson058e31e2009-01-16 03:54:08 +0000279---------------
280
Vinay Sajipc63619b2010-12-19 12:56:57 +0000281Handlers have the following attributes and methods. Note that :class:`Handler`
282is never instantiated directly; this class acts as a base for more useful
283subclasses. However, the :meth:`__init__` method in subclasses needs to call
284:meth:`Handler.__init__`.
Georg Brandl116aa622007-08-15 14:28:22 +0000285
Georg Brandl116aa622007-08-15 14:28:22 +0000286
Vinay Sajipc63619b2010-12-19 12:56:57 +0000287.. method:: Handler.__init__(level=NOTSET)
Georg Brandl116aa622007-08-15 14:28:22 +0000288
Vinay Sajipc63619b2010-12-19 12:56:57 +0000289 Initializes the :class:`Handler` instance by setting its level, setting the list
290 of filters to the empty list and creating a lock (using :meth:`createLock`) for
291 serializing access to an I/O mechanism.
Vinay Sajip30bf1222009-01-10 19:23:34 +0000292
Georg Brandl116aa622007-08-15 14:28:22 +0000293
Vinay Sajipc63619b2010-12-19 12:56:57 +0000294.. method:: Handler.createLock()
Georg Brandl116aa622007-08-15 14:28:22 +0000295
Vinay Sajipc63619b2010-12-19 12:56:57 +0000296 Initializes a thread lock which can be used to serialize access to underlying
297 I/O functionality which may not be threadsafe.
Georg Brandl116aa622007-08-15 14:28:22 +0000298
Georg Brandl116aa622007-08-15 14:28:22 +0000299
Vinay Sajipc63619b2010-12-19 12:56:57 +0000300.. method:: Handler.acquire()
Georg Brandl116aa622007-08-15 14:28:22 +0000301
Vinay Sajipc63619b2010-12-19 12:56:57 +0000302 Acquires the thread lock created with :meth:`createLock`.
Georg Brandl116aa622007-08-15 14:28:22 +0000303
Georg Brandl116aa622007-08-15 14:28:22 +0000304
Vinay Sajipc63619b2010-12-19 12:56:57 +0000305.. method:: Handler.release()
Georg Brandl116aa622007-08-15 14:28:22 +0000306
Vinay Sajipc63619b2010-12-19 12:56:57 +0000307 Releases the thread lock acquired with :meth:`acquire`.
Georg Brandl116aa622007-08-15 14:28:22 +0000308
Georg Brandl116aa622007-08-15 14:28:22 +0000309
Vinay Sajipc63619b2010-12-19 12:56:57 +0000310.. method:: Handler.setLevel(lvl)
Vinay Sajip30bf1222009-01-10 19:23:34 +0000311
Vinay Sajipc63619b2010-12-19 12:56:57 +0000312 Sets the threshold for this handler to *lvl*. Logging messages which are less
313 severe than *lvl* will be ignored. When a handler is created, the level is set
314 to :const:`NOTSET` (which causes all messages to be processed).
315
316
317.. method:: Handler.setFormatter(form)
318
319 Sets the :class:`Formatter` for this handler to *form*.
320
321
322.. method:: Handler.addFilter(filt)
323
324 Adds the specified filter *filt* to this handler.
325
326
327.. method:: Handler.removeFilter(filt)
328
329 Removes the specified filter *filt* from this handler.
330
331
332.. method:: Handler.filter(record)
333
334 Applies this handler's filters to the record and returns a true value if the
335 record is to be processed.
336
337
338.. method:: Handler.flush()
339
340 Ensure all logging output has been flushed. This version does nothing and is
341 intended to be implemented by subclasses.
342
343
344.. method:: Handler.close()
345
346 Tidy up any resources used by the handler. This version does no output but
347 removes the handler from an internal list of handlers which is closed when
348 :func:`shutdown` is called. Subclasses should ensure that this gets called
349 from overridden :meth:`close` methods.
350
351
352.. method:: Handler.handle(record)
353
354 Conditionally emits the specified logging record, depending on filters which may
355 have been added to the handler. Wraps the actual emission of the record with
356 acquisition/release of the I/O thread lock.
357
358
359.. method:: Handler.handleError(record)
360
361 This method should be called from handlers when an exception is encountered
362 during an :meth:`emit` call. By default it does nothing, which means that
363 exceptions get silently ignored. This is what is mostly wanted for a logging
364 system - most users will not care about errors in the logging system, they are
365 more interested in application errors. You could, however, replace this with a
366 custom handler if you wish. The specified record is the one which was being
367 processed when the exception occurred.
368
369
370.. method:: Handler.format(record)
371
372 Do formatting for a record - if a formatter is set, use it. Otherwise, use the
373 default formatter for the module.
374
375
376.. method:: Handler.emit(record)
377
378 Do whatever it takes to actually log the specified logging record. This version
379 is intended to be implemented by subclasses and so raises a
380 :exc:`NotImplementedError`.
381
382For a list of handlers included as standard, see :mod:`logging.handlers`.
383
384.. _formatter-objects:
385
386Formatter Objects
387-----------------
Vinay Sajip121a1c42010-09-08 10:46:15 +0000388
Vinay Sajip30bf1222009-01-10 19:23:34 +0000389.. currentmodule:: logging
390
Vinay Sajipc63619b2010-12-19 12:56:57 +0000391:class:`Formatter` objects have the following attributes and methods. They are
392responsible for converting a :class:`LogRecord` to (usually) a string which can
393be interpreted by either a human or an external system. The base
394:class:`Formatter` allows a formatting string to be specified. If none is
395supplied, the default value of ``'%(message)s'`` is used.
Georg Brandlf9734072008-12-07 15:30:06 +0000396
Vinay Sajipc63619b2010-12-19 12:56:57 +0000397A Formatter can be initialized with a format string which makes use of knowledge
398of the :class:`LogRecord` attributes - such as the default value mentioned above
399making use of the fact that the user's message and arguments are pre-formatted
400into a :class:`LogRecord`'s *message* attribute. This format string contains
401standard Python %-style mapping keys. See section :ref:`old-string-formatting`
402for more information on string formatting.
Georg Brandlf9734072008-12-07 15:30:06 +0000403
Vinay Sajipc63619b2010-12-19 12:56:57 +0000404The useful mapping keys in a :class:`LogRecord` are given in the section on
405:ref:`logrecord-attributes`.
Vinay Sajip121a1c42010-09-08 10:46:15 +0000406
Georg Brandl116aa622007-08-15 14:28:22 +0000407
Vinay Sajipc46102c2011-04-08 01:30:51 +0100408.. class:: Formatter(fmt=None, datefmt=None, style='%')
Georg Brandl116aa622007-08-15 14:28:22 +0000409
Vinay Sajipc63619b2010-12-19 12:56:57 +0000410 Returns a new instance of the :class:`Formatter` class. The instance is
411 initialized with a format string for the message as a whole, as well as a
412 format string for the date/time portion of a message. If no *fmt* is
413 specified, ``'%(message)s'`` is used. If no *datefmt* is specified, the
414 ISO8601 date format is used.
Georg Brandl116aa622007-08-15 14:28:22 +0000415
Vinay Sajipc46102c2011-04-08 01:30:51 +0100416 The *style* parameter can be one of '%', '{' or '$' and determines how
417 the format string will be merged with its data: using one of %-formatting,
Vinay Sajip77f8d292011-04-08 01:34:20 +0100418 :meth:`str.format` or :class:`string.Template`.
Vinay Sajipc46102c2011-04-08 01:30:51 +0100419
420 .. versionchanged:: 3.2
421 The *style* parameter was added.
422
423
Vinay Sajipc63619b2010-12-19 12:56:57 +0000424 .. method:: format(record)
Georg Brandl116aa622007-08-15 14:28:22 +0000425
Vinay Sajipc63619b2010-12-19 12:56:57 +0000426 The record's attribute dictionary is used as the operand to a string
427 formatting operation. Returns the resulting string. Before formatting the
428 dictionary, a couple of preparatory steps are carried out. The *message*
429 attribute of the record is computed using *msg* % *args*. If the
430 formatting string contains ``'(asctime)'``, :meth:`formatTime` is called
431 to format the event time. If there is exception information, it is
432 formatted using :meth:`formatException` and appended to the message. Note
433 that the formatted exception information is cached in attribute
434 *exc_text*. This is useful because the exception information can be
435 pickled and sent across the wire, but you should be careful if you have
436 more than one :class:`Formatter` subclass which customizes the formatting
437 of exception information. In this case, you will have to clear the cached
438 value after a formatter has done its formatting, so that the next
439 formatter to handle the event doesn't use the cached value but
440 recalculates it afresh.
441
442 If stack information is available, it's appended after the exception
443 information, using :meth:`formatStack` to transform it if necessary.
444
445
446 .. method:: formatTime(record, datefmt=None)
447
448 This method should be called from :meth:`format` by a formatter which
449 wants to make use of a formatted time. This method can be overridden in
450 formatters to provide for any specific requirement, but the basic behavior
451 is as follows: if *datefmt* (a string) is specified, it is used with
452 :func:`time.strftime` to format the creation time of the
453 record. Otherwise, the ISO8601 format is used. The resulting string is
454 returned.
455
456
457 .. method:: formatException(exc_info)
458
459 Formats the specified exception information (a standard exception tuple as
460 returned by :func:`sys.exc_info`) as a string. This default implementation
461 just uses :func:`traceback.print_exception`. The resulting string is
462 returned.
463
464 .. method:: formatStack(stack_info)
465
466 Formats the specified stack information (a string as returned by
467 :func:`traceback.print_stack`, but with the last newline removed) as a
468 string. This default implementation just returns the input value.
469
470.. _filter:
471
472Filter Objects
473--------------
474
475``Filters`` can be used by ``Handlers`` and ``Loggers`` for more sophisticated
476filtering than is provided by levels. The base filter class only allows events
477which are below a certain point in the logger hierarchy. For example, a filter
478initialized with 'A.B' will allow events logged by loggers 'A.B', 'A.B.C',
479'A.B.C.D', 'A.B.D' etc. but not 'A.BB', 'B.A.B' etc. If initialized with the
480empty string, all events are passed.
481
482
483.. class:: Filter(name='')
484
485 Returns an instance of the :class:`Filter` class. If *name* is specified, it
486 names a logger which, together with its children, will have its events allowed
487 through the filter. If *name* is the empty string, allows every event.
488
489
490 .. method:: filter(record)
491
492 Is the specified record to be logged? Returns zero for no, nonzero for
493 yes. If deemed appropriate, the record may be modified in-place by this
494 method.
495
496Note that filters attached to handlers are consulted whenever an event is
497emitted by the handler, whereas filters attached to loggers are consulted
498whenever an event is logged to the handler (using :meth:`debug`, :meth:`info`,
499etc.) This means that events which have been generated by descendant loggers
500will not be filtered by a logger's filter setting, unless the filter has also
501been applied to those descendant loggers.
502
503You don't actually need to subclass ``Filter``: you can pass any instance
504which has a ``filter`` method with the same semantics.
505
506.. versionchanged:: 3.2
507 You don't need to create specialized ``Filter`` classes, or use other
508 classes with a ``filter`` method: you can use a function (or other
509 callable) as a filter. The filtering logic will check to see if the filter
510 object has a ``filter`` attribute: if it does, it's assumed to be a
511 ``Filter`` and its :meth:`~Filter.filter` method is called. Otherwise, it's
512 assumed to be a callable and called with the record as the single
513 parameter. The returned value should conform to that returned by
514 :meth:`~Filter.filter`.
515
516Although filters are used primarily to filter records based on more
517sophisticated criteria than levels, they get to see every record which is
518processed by the handler or logger they're attached to: this can be useful if
519you want to do things like counting how many records were processed by a
520particular logger or handler, or adding, changing or removing attributes in
521the LogRecord being processed. Obviously changing the LogRecord needs to be
522done with some care, but it does allow the injection of contextual information
523into logs (see :ref:`filters-contextual`).
524
525.. _log-record:
526
527LogRecord Objects
528-----------------
529
530:class:`LogRecord` instances are created automatically by the :class:`Logger`
531every time something is logged, and can be created manually via
532:func:`makeLogRecord` (for example, from a pickled event received over the
533wire).
534
535
536.. class:: LogRecord(name, level, pathname, lineno, msg, args, exc_info, func=None, sinfo=None)
537
538 Contains all the information pertinent to the event being logged.
539
540 The primary information is passed in :attr:`msg` and :attr:`args`, which
541 are combined using ``msg % args`` to create the :attr:`message` field of the
542 record.
543
544 :param name: The name of the logger used to log the event represented by
545 this LogRecord.
546 :param level: The numeric level of the logging event (one of DEBUG, INFO etc.)
547 :param pathname: The full pathname of the source file where the logging call
548 was made.
549 :param lineno: The line number in the source file where the logging call was
550 made.
551 :param msg: The event description message, possibly a format string with
552 placeholders for variable data.
553 :param args: Variable data to merge into the *msg* argument to obtain the
554 event description.
555 :param exc_info: An exception tuple with the current exception information,
556 or *None* if no exception information is available.
557 :param func: The name of the function or method from which the logging call
558 was invoked.
559 :param sinfo: A text string representing stack information from the base of
560 the stack in the current thread, up to the logging call.
561
562 .. method:: getMessage()
563
564 Returns the message for this :class:`LogRecord` instance after merging any
565 user-supplied arguments with the message. If the user-supplied message
566 argument to the logging call is not a string, :func:`str` is called on it to
567 convert it to a string. This allows use of user-defined classes as
568 messages, whose ``__str__`` method can return the actual format string to
569 be used.
570
571 .. versionchanged:: 3.2
572 The creation of a ``LogRecord`` has been made more configurable by
573 providing a factory which is used to create the record. The factory can be
574 set using :func:`getLogRecordFactory` and :func:`setLogRecordFactory`
575 (see this for the factory's signature).
576
577 This functionality can be used to inject your own values into a
578 LogRecord at creation time. You can use the following pattern::
579
580 old_factory = logging.getLogRecordFactory()
581
582 def record_factory(*args, **kwargs):
583 record = old_factory(*args, **kwargs)
584 record.custom_attribute = 0xdecafbad
585 return record
586
587 logging.setLogRecordFactory(record_factory)
588
589 With this pattern, multiple factories could be chained, and as long
590 as they don't overwrite each other's attributes or unintentionally
591 overwrite the standard attributes listed above, there should be no
592 surprises.
593
594
595.. _logrecord-attributes:
596
597LogRecord attributes
598--------------------
599
600The LogRecord has a number of attributes, most of which are derived from the
601parameters to the constructor. (Note that the names do not always correspond
602exactly between the LogRecord constructor parameters and the LogRecord
603attributes.) These attributes can be used to merge data from the record into
604the format string. The following table lists (in alphabetical order) the
605attribute names, their meanings and the corresponding placeholder in a %-style
606format string.
607
608If you are using {}-formatting (:func:`str.format`), you can use
609``{attrname}`` as the placeholder in the format string. If you are using
610$-formatting (:class:`string.Template`), use the form ``${attrname}``. In
611both cases, of course, replace ``attrname`` with the actual attribute name
612you want to use.
613
614In the case of {}-formatting, you can specify formatting flags by placing them
615after the attribute name, separated from it with a colon. For example: a
616placeholder of ``{msecs:03d}`` would format a millisecond value of ``4`` as
617``004``. Refer to the :meth:`str.format` documentation for full details on
618the options available to you.
619
620+----------------+-------------------------+-----------------------------------------------+
621| Attribute name | Format | Description |
622+================+=========================+===============================================+
623| args | You shouldn't need to | The tuple of arguments merged into ``msg`` to |
624| | format this yourself. | produce ``message``. |
625+----------------+-------------------------+-----------------------------------------------+
626| asctime | ``%(asctime)s`` | Human-readable time when the |
627| | | :class:`LogRecord` was created. By default |
628| | | this is of the form '2003-07-08 16:49:45,896' |
629| | | (the numbers after the comma are millisecond |
630| | | portion of the time). |
631+----------------+-------------------------+-----------------------------------------------+
632| created | ``%(created)f`` | Time when the :class:`LogRecord` was created |
633| | | (as returned by :func:`time.time`). |
634+----------------+-------------------------+-----------------------------------------------+
635| exc_info | You shouldn't need to | Exception tuple (à la ``sys.exc_info``) or, |
636| | format this yourself. | if no exception has occurred, *None*. |
637+----------------+-------------------------+-----------------------------------------------+
638| filename | ``%(filename)s`` | Filename portion of ``pathname``. |
639+----------------+-------------------------+-----------------------------------------------+
640| funcName | ``%(funcName)s`` | Name of function containing the logging call. |
641+----------------+-------------------------+-----------------------------------------------+
642| levelname | ``%(levelname)s`` | Text logging level for the message |
643| | | (``'DEBUG'``, ``'INFO'``, ``'WARNING'``, |
644| | | ``'ERROR'``, ``'CRITICAL'``). |
645+----------------+-------------------------+-----------------------------------------------+
646| levelno | ``%(levelno)s`` | Numeric logging level for the message |
647| | | (:const:`DEBUG`, :const:`INFO`, |
648| | | :const:`WARNING`, :const:`ERROR`, |
649| | | :const:`CRITICAL`). |
650+----------------+-------------------------+-----------------------------------------------+
651| lineno | ``%(lineno)d`` | Source line number where the logging call was |
652| | | issued (if available). |
653+----------------+-------------------------+-----------------------------------------------+
654| module | ``%(module)s`` | Module (name portion of ``filename``). |
655+----------------+-------------------------+-----------------------------------------------+
656| msecs | ``%(msecs)d`` | Millisecond portion of the time when the |
657| | | :class:`LogRecord` was created. |
658+----------------+-------------------------+-----------------------------------------------+
659| message | ``%(message)s`` | The logged message, computed as ``msg % |
660| | | args``. This is set when |
661| | | :meth:`Formatter.format` is invoked. |
662+----------------+-------------------------+-----------------------------------------------+
663| msg | You shouldn't need to | The format string passed in the original |
664| | format this yourself. | logging call. Merged with ``args`` to |
665| | | produce ``message``, or an arbitrary object |
666| | | (see :ref:`arbitrary-object-messages`). |
667+----------------+-------------------------+-----------------------------------------------+
668| name | ``%(name)s`` | Name of the logger used to log the call. |
669+----------------+-------------------------+-----------------------------------------------+
670| pathname | ``%(pathname)s`` | Full pathname of the source file where the |
671| | | logging call was issued (if available). |
672+----------------+-------------------------+-----------------------------------------------+
673| process | ``%(process)d`` | Process ID (if available). |
674+----------------+-------------------------+-----------------------------------------------+
675| processName | ``%(processName)s`` | Process name (if available). |
676+----------------+-------------------------+-----------------------------------------------+
677| relativeCreated| ``%(relativeCreated)d`` | Time in milliseconds when the LogRecord was |
678| | | created, relative to the time the logging |
679| | | module was loaded. |
680+----------------+-------------------------+-----------------------------------------------+
681| stack_info | You shouldn't need to | Stack frame information (where available) |
682| | format this yourself. | from the bottom of the stack in the current |
683| | | thread, up to and including the stack frame |
684| | | of the logging call which resulted in the |
685| | | creation of this record. |
686+----------------+-------------------------+-----------------------------------------------+
687| thread | ``%(thread)d`` | Thread ID (if available). |
688+----------------+-------------------------+-----------------------------------------------+
689| threadName | ``%(threadName)s`` | Thread name (if available). |
690+----------------+-------------------------+-----------------------------------------------+
691
692
693.. _logger-adapter:
694
695LoggerAdapter Objects
696---------------------
697
698:class:`LoggerAdapter` instances are used to conveniently pass contextual
699information into logging calls. For a usage example , see the section on
700:ref:`adding contextual information to your logging output <context-info>`.
701
Vinay Sajipc63619b2010-12-19 12:56:57 +0000702.. class:: LoggerAdapter(logger, extra)
703
704 Returns an instance of :class:`LoggerAdapter` initialized with an
705 underlying :class:`Logger` instance and a dict-like object.
706
707 .. method:: process(msg, kwargs)
708
709 Modifies the message and/or keyword arguments passed to a logging call in
710 order to insert contextual information. This implementation takes the object
711 passed as *extra* to the constructor and adds it to *kwargs* using key
712 'extra'. The return value is a (*msg*, *kwargs*) tuple which has the
713 (possibly modified) versions of the arguments passed in.
714
715In addition to the above, :class:`LoggerAdapter` supports the following
716methods of :class:`Logger`, i.e. :meth:`debug`, :meth:`info`, :meth:`warning`,
717:meth:`error`, :meth:`exception`, :meth:`critical`, :meth:`log`,
718:meth:`isEnabledFor`, :meth:`getEffectiveLevel`, :meth:`setLevel`,
719:meth:`hasHandlers`. These methods have the same signatures as their
720counterparts in :class:`Logger`, so you can use the two types of instances
721interchangeably.
722
723.. versionchanged:: 3.2
724 The :meth:`isEnabledFor`, :meth:`getEffectiveLevel`, :meth:`setLevel` and
725 :meth:`hasHandlers` methods were added to :class:`LoggerAdapter`. These
726 methods delegate to the underlying logger.
727
728
729Thread Safety
730-------------
731
732The logging module is intended to be thread-safe without any special work
733needing to be done by its clients. It achieves this though using threading
734locks; there is one lock to serialize access to the module's shared data, and
735each handler also creates a lock to serialize access to its underlying I/O.
736
737If you are implementing asynchronous signal handlers using the :mod:`signal`
738module, you may not be able to use logging from within such handlers. This is
739because lock implementations in the :mod:`threading` module are not always
740re-entrant, and so cannot be invoked from such signal handlers.
741
Georg Brandl116aa622007-08-15 14:28:22 +0000742
Benjamin Peterson058e31e2009-01-16 03:54:08 +0000743Module-Level Functions
744----------------------
745
Georg Brandl116aa622007-08-15 14:28:22 +0000746In addition to the classes described above, there are a number of module- level
747functions.
748
749
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000750.. function:: getLogger(name=None)
Georg Brandl116aa622007-08-15 14:28:22 +0000751
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000752 Return a logger with the specified name or, if name is ``None``, return a
Georg Brandl116aa622007-08-15 14:28:22 +0000753 logger which is the root logger of the hierarchy. If specified, the name is
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000754 typically a dot-separated hierarchical name like *'a'*, *'a.b'* or *'a.b.c.d'*.
Georg Brandl116aa622007-08-15 14:28:22 +0000755 Choice of these names is entirely up to the developer who is using logging.
756
757 All calls to this function with a given name return the same logger instance.
758 This means that logger instances never need to be passed between different parts
759 of an application.
760
761
762.. function:: getLoggerClass()
763
764 Return either the standard :class:`Logger` class, or the last class passed to
765 :func:`setLoggerClass`. This function may be called from within a new class
766 definition, to ensure that installing a customised :class:`Logger` class will
767 not undo customisations already applied by other code. For example::
768
769 class MyLogger(logging.getLoggerClass()):
770 # ... override behaviour here
771
772
Vinay Sajip61561522010-12-03 11:50:38 +0000773.. function:: getLogRecordFactory()
774
775 Return a callable which is used to create a :class:`LogRecord`.
776
777 .. versionadded:: 3.2
Vinay Sajip61561522010-12-03 11:50:38 +0000778 This function has been provided, along with :func:`setLogRecordFactory`,
779 to allow developers more control over how the :class:`LogRecord`
780 representing a logging event is constructed.
781
782 See :func:`setLogRecordFactory` for more information about the how the
783 factory is called.
784
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000785.. function:: debug(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000786
787 Logs a message with level :const:`DEBUG` on the root logger. The *msg* is the
788 message format string, and the *args* are the arguments which are merged into
789 *msg* using the string formatting operator. (Note that this means that you can
790 use keywords in the format string, together with a single dictionary argument.)
791
Vinay Sajip8593ae62010-11-14 21:33:04 +0000792 There are three keyword arguments in *kwargs* which are inspected: *exc_info*
Georg Brandl116aa622007-08-15 14:28:22 +0000793 which, if it does not evaluate as false, causes exception information to be
794 added to the logging message. If an exception tuple (in the format returned by
795 :func:`sys.exc_info`) is provided, it is used; otherwise, :func:`sys.exc_info`
796 is called to get the exception information.
797
Vinay Sajip8593ae62010-11-14 21:33:04 +0000798 The second optional keyword argument is *stack_info*, which defaults to
799 False. If specified as True, stack information is added to the logging
800 message, including the actual logging call. Note that this is not the same
801 stack information as that displayed through specifying *exc_info*: The
802 former is stack frames from the bottom of the stack up to the logging call
803 in the current thread, whereas the latter is information about stack frames
804 which have been unwound, following an exception, while searching for
805 exception handlers.
806
807 You can specify *stack_info* independently of *exc_info*, e.g. to just show
808 how you got to a certain point in your code, even when no exceptions were
809 raised. The stack frames are printed following a header line which says::
810
811 Stack (most recent call last):
812
813 This mimics the `Traceback (most recent call last):` which is used when
814 displaying exception frames.
815
816 The third optional keyword argument is *extra* which can be used to pass a
Georg Brandl116aa622007-08-15 14:28:22 +0000817 dictionary which is used to populate the __dict__ of the LogRecord created for
818 the logging event with user-defined attributes. These custom attributes can then
819 be used as you like. For example, they could be incorporated into logged
820 messages. For example::
821
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000822 FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
Georg Brandl116aa622007-08-15 14:28:22 +0000823 logging.basicConfig(format=FORMAT)
824 d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000825 logging.warning('Protocol problem: %s', 'connection reset', extra=d)
Georg Brandl116aa622007-08-15 14:28:22 +0000826
Vinay Sajip4039aff2010-09-11 10:25:28 +0000827 would print something like::
Georg Brandl116aa622007-08-15 14:28:22 +0000828
829 2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset
830
831 The keys in the dictionary passed in *extra* should not clash with the keys used
832 by the logging system. (See the :class:`Formatter` documentation for more
833 information on which keys are used by the logging system.)
834
835 If you choose to use these attributes in logged messages, you need to exercise
836 some care. In the above example, for instance, the :class:`Formatter` has been
837 set up with a format string which expects 'clientip' and 'user' in the attribute
838 dictionary of the LogRecord. If these are missing, the message will not be
839 logged because a string formatting exception will occur. So in this case, you
840 always need to pass the *extra* dictionary with these keys.
841
842 While this might be annoying, this feature is intended for use in specialized
843 circumstances, such as multi-threaded servers where the same code executes in
844 many contexts, and interesting conditions which arise are dependent on this
845 context (such as remote client IP address and authenticated user name, in the
846 above example). In such circumstances, it is likely that specialized
847 :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
848
Vinay Sajip8593ae62010-11-14 21:33:04 +0000849 .. versionadded:: 3.2
850 The *stack_info* parameter was added.
Georg Brandl116aa622007-08-15 14:28:22 +0000851
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000852.. function:: info(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000853
854 Logs a message with level :const:`INFO` on the root logger. The arguments are
855 interpreted as for :func:`debug`.
856
857
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000858.. function:: warning(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000859
860 Logs a message with level :const:`WARNING` on the root logger. The arguments are
861 interpreted as for :func:`debug`.
862
863
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000864.. function:: error(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000865
866 Logs a message with level :const:`ERROR` on the root logger. The arguments are
867 interpreted as for :func:`debug`.
868
869
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000870.. function:: critical(msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000871
872 Logs a message with level :const:`CRITICAL` on the root logger. The arguments
873 are interpreted as for :func:`debug`.
874
875
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000876.. function:: exception(msg, *args)
Georg Brandl116aa622007-08-15 14:28:22 +0000877
878 Logs a message with level :const:`ERROR` on the root logger. The arguments are
879 interpreted as for :func:`debug`. Exception info is added to the logging
880 message. This function should only be called from an exception handler.
881
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000882.. function:: log(level, msg, *args, **kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000883
884 Logs a message with level *level* on the root logger. The other arguments are
885 interpreted as for :func:`debug`.
886
Vinay Sajipc8c8c692010-09-17 10:09:04 +0000887 PLEASE NOTE: The above module-level functions which delegate to the root
888 logger should *not* be used in threads, in versions of Python earlier than
889 2.7.1 and 3.2, unless at least one handler has been added to the root
890 logger *before* the threads are started. These convenience functions call
891 :func:`basicConfig` to ensure that at least one handler is available; in
892 earlier versions of Python, this can (under rare circumstances) lead to
893 handlers being added multiple times to the root logger, which can in turn
894 lead to multiple messages for the same event.
Georg Brandl116aa622007-08-15 14:28:22 +0000895
896.. function:: disable(lvl)
897
898 Provides an overriding level *lvl* for all loggers which takes precedence over
899 the logger's own level. When the need arises to temporarily throttle logging
Benjamin Peterson886af962010-03-21 23:13:07 +0000900 output down across the whole application, this function can be useful. Its
901 effect is to disable all logging calls of severity *lvl* and below, so that
902 if you call it with a value of INFO, then all INFO and DEBUG events would be
903 discarded, whereas those of severity WARNING and above would be processed
904 according to the logger's effective level.
Georg Brandl116aa622007-08-15 14:28:22 +0000905
906
907.. function:: addLevelName(lvl, levelName)
908
909 Associates level *lvl* with text *levelName* in an internal dictionary, which is
910 used to map numeric levels to a textual representation, for example when a
911 :class:`Formatter` formats a message. This function can also be used to define
912 your own levels. The only constraints are that all levels used must be
913 registered using this function, levels should be positive integers and they
914 should increase in increasing order of severity.
915
Vinay Sajipc8c8c692010-09-17 10:09:04 +0000916 NOTE: If you are thinking of defining your own levels, please see the section
917 on :ref:`custom-levels`.
Georg Brandl116aa622007-08-15 14:28:22 +0000918
919.. function:: getLevelName(lvl)
920
921 Returns the textual representation of logging level *lvl*. If the level is one
922 of the predefined levels :const:`CRITICAL`, :const:`ERROR`, :const:`WARNING`,
923 :const:`INFO` or :const:`DEBUG` then you get the corresponding string. If you
924 have associated levels with names using :func:`addLevelName` then the name you
925 have associated with *lvl* is returned. If a numeric value corresponding to one
926 of the defined levels is passed in, the corresponding string representation is
Vinay Sajip9a6b4002010-12-14 19:40:21 +0000927 returned. Otherwise, the string 'Level %s' % lvl is returned.
Georg Brandl116aa622007-08-15 14:28:22 +0000928
929
930.. function:: makeLogRecord(attrdict)
931
932 Creates and returns a new :class:`LogRecord` instance whose attributes are
933 defined by *attrdict*. This function is useful for taking a pickled
934 :class:`LogRecord` attribute dictionary, sent over a socket, and reconstituting
935 it as a :class:`LogRecord` instance at the receiving end.
936
937
Georg Brandlcd7f32b2009-06-08 09:13:45 +0000938.. function:: basicConfig(**kwargs)
Georg Brandl116aa622007-08-15 14:28:22 +0000939
940 Does basic configuration for the logging system by creating a
941 :class:`StreamHandler` with a default :class:`Formatter` and adding it to the
Vinay Sajipcbabd7e2009-10-10 20:32:36 +0000942 root logger. The functions :func:`debug`, :func:`info`, :func:`warning`,
Georg Brandl116aa622007-08-15 14:28:22 +0000943 :func:`error` and :func:`critical` will call :func:`basicConfig` automatically
944 if no handlers are defined for the root logger.
945
Vinay Sajipcbabd7e2009-10-10 20:32:36 +0000946 This function does nothing if the root logger already has handlers
947 configured for it.
948
Vinay Sajipc8c8c692010-09-17 10:09:04 +0000949 PLEASE NOTE: This function should be called from the main thread
950 before other threads are started. In versions of Python prior to
951 2.7.1 and 3.2, if this function is called from multiple threads,
952 it is possible (in rare circumstances) that a handler will be added
953 to the root logger more than once, leading to unexpected results
954 such as messages being duplicated in the log.
955
Georg Brandl116aa622007-08-15 14:28:22 +0000956 The following keyword arguments are supported.
957
958 +--------------+---------------------------------------------+
959 | Format | Description |
960 +==============+=============================================+
961 | ``filename`` | Specifies that a FileHandler be created, |
962 | | using the specified filename, rather than a |
963 | | StreamHandler. |
964 +--------------+---------------------------------------------+
965 | ``filemode`` | Specifies the mode to open the file, if |
966 | | filename is specified (if filemode is |
967 | | unspecified, it defaults to 'a'). |
968 +--------------+---------------------------------------------+
969 | ``format`` | Use the specified format string for the |
970 | | handler. |
971 +--------------+---------------------------------------------+
972 | ``datefmt`` | Use the specified date/time format. |
973 +--------------+---------------------------------------------+
Vinay Sajipc5b27302010-10-31 14:59:16 +0000974 | ``style`` | If ``format`` is specified, use this style |
975 | | for the format string. One of '%', '{' or |
976 | | '$' for %-formatting, :meth:`str.format` or |
977 | | :class:`string.Template` respectively, and |
978 | | defaulting to '%' if not specified. |
979 +--------------+---------------------------------------------+
Georg Brandl116aa622007-08-15 14:28:22 +0000980 | ``level`` | Set the root logger level to the specified |
981 | | level. |
982 +--------------+---------------------------------------------+
983 | ``stream`` | Use the specified stream to initialize the |
984 | | StreamHandler. Note that this argument is |
985 | | incompatible with 'filename' - if both are |
986 | | present, 'stream' is ignored. |
987 +--------------+---------------------------------------------+
988
Vinay Sajipc5b27302010-10-31 14:59:16 +0000989 .. versionchanged:: 3.2
990 The ``style`` argument was added.
991
992
Georg Brandl116aa622007-08-15 14:28:22 +0000993.. function:: shutdown()
994
995 Informs the logging system to perform an orderly shutdown by flushing and
Christian Heimesb186d002008-03-18 15:15:01 +0000996 closing all handlers. This should be called at application exit and no
997 further use of the logging system should be made after this call.
Georg Brandl116aa622007-08-15 14:28:22 +0000998
999
1000.. function:: setLoggerClass(klass)
1001
1002 Tells the logging system to use the class *klass* when instantiating a logger.
1003 The class should define :meth:`__init__` such that only a name argument is
1004 required, and the :meth:`__init__` should call :meth:`Logger.__init__`. This
1005 function is typically called before any loggers are instantiated by applications
1006 which need to use custom logger behavior.
1007
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001008
Vinay Sajip61561522010-12-03 11:50:38 +00001009.. function:: setLogRecordFactory(factory)
1010
1011 Set a callable which is used to create a :class:`LogRecord`.
1012
1013 :param factory: The factory callable to be used to instantiate a log record.
1014
1015 .. versionadded:: 3.2
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001016 This function has been provided, along with :func:`getLogRecordFactory`, to
1017 allow developers more control over how the :class:`LogRecord` representing
1018 a logging event is constructed.
Vinay Sajip61561522010-12-03 11:50:38 +00001019
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001020 The factory has the following signature:
Vinay Sajip61561522010-12-03 11:50:38 +00001021
Vinay Sajip9a6b4002010-12-14 19:40:21 +00001022 ``factory(name, level, fn, lno, msg, args, exc_info, func=None, sinfo=None, **kwargs)``
Vinay Sajip61561522010-12-03 11:50:38 +00001023
1024 :name: The logger name.
1025 :level: The logging level (numeric).
1026 :fn: The full pathname of the file where the logging call was made.
1027 :lno: The line number in the file where the logging call was made.
1028 :msg: The logging message.
1029 :args: The arguments for the logging message.
1030 :exc_info: An exception tuple, or None.
1031 :func: The name of the function or method which invoked the logging
1032 call.
1033 :sinfo: A stack traceback such as is provided by
1034 :func:`traceback.print_stack`, showing the call hierarchy.
1035 :kwargs: Additional keyword arguments.
Georg Brandl116aa622007-08-15 14:28:22 +00001036
Georg Brandl1eb40bc2010-12-03 15:30:09 +00001037
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001038Integration with the warnings module
1039------------------------------------
1040
1041The :func:`captureWarnings` function can be used to integrate :mod:`logging`
1042with the :mod:`warnings` module.
1043
1044.. function:: captureWarnings(capture)
1045
1046 This function is used to turn the capture of warnings by logging on and
1047 off.
1048
Senthil Kumaran46a48be2010-10-15 13:10:10 +00001049 If *capture* is ``True``, warnings issued by the :mod:`warnings` module will
1050 be redirected to the logging system. Specifically, a warning will be
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001051 formatted using :func:`warnings.formatwarning` and the resulting string
Vinay Sajip9a6b4002010-12-14 19:40:21 +00001052 logged to a logger named 'py.warnings' with a severity of `WARNING`.
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001053
Senthil Kumaran46a48be2010-10-15 13:10:10 +00001054 If *capture* is ``False``, the redirection of warnings to the logging system
Benjamin Peterson9451a1c2010-03-13 22:30:34 +00001055 will stop, and warnings will be redirected to their original destinations
1056 (i.e. those in effect before `captureWarnings(True)` was called).
1057
1058
Vinay Sajipc63619b2010-12-19 12:56:57 +00001059.. seealso::
Vinay Sajip75043022010-12-19 06:02:31 +00001060
Vinay Sajipc63619b2010-12-19 12:56:57 +00001061 Module :mod:`logging.config`
1062 Configuration API for the logging module.
Georg Brandl116aa622007-08-15 14:28:22 +00001063
Vinay Sajipc63619b2010-12-19 12:56:57 +00001064 Module :mod:`logging.handlers`
1065 Useful handlers included with the logging module.
Georg Brandl116aa622007-08-15 14:28:22 +00001066
Vinay Sajipc63619b2010-12-19 12:56:57 +00001067 :pep:`282` - A Logging System
1068 The proposal which described this feature for inclusion in the Python standard
1069 library.
Georg Brandl116aa622007-08-15 14:28:22 +00001070
Vinay Sajipc63619b2010-12-19 12:56:57 +00001071 `Original Python logging package <http://www.red-dove.com/python_logging.html>`_
1072 This is the original source for the :mod:`logging` package. The version of the
1073 package available from this site is suitable for use with Python 1.5.2, 2.1.x
1074 and 2.2.x, which do not include the :mod:`logging` package in the standard
1075 library.
Christian Heimes8b0facf2007-12-04 19:30:01 +00001076