1. Nick Coghlan
  2. cpython_sandbox


cpython_sandbox / Doc / library / logging.rst

:mod:`logging` --- Logging facility for Python

This module defines functions and classes which implement a flexible event logging system for applications and libraries.

The key benefit of having the logging API provided by a standard library module is that all Python modules can participate in logging, so your application log can include your own messages integrated with messages from third-party modules.

The module provides a lot of functionality and flexibility. If you are unfamiliar with logging, the best way to get to grips with it is to see the tutorials (see the links on the right).

The basic classes defined by the module, together with their functions, are listed below.

  • Loggers expose the interface that application code directly uses.
  • Handlers send the log records (created by loggers) to the appropriate destination.
  • Filters provide a finer grained facility for determining which log records to output.
  • Formatters specify the layout of log records in the final output.

Logger Objects

Loggers have the following attributes and methods. Note that Loggers are never instantiated directly, but always through the module-level function logging.getLogger(name). Multiple calls to :func:`getLogger` with the same name will always return a reference to the same Logger object.

The name is potentially a period-separated hierarchical value, like foo.bar.baz (though it could also be just plain foo, for example). Loggers that are further down in the hierarchical list are children of loggers higher up in the list. For example, given a logger with a name of foo, loggers with names of foo.bar, foo.bar.baz, and foo.bam are all descendants of foo. The logger name hierarchy is analogous to the Python package hierarchy, and identical to it if you organise your loggers on a per-module basis using the recommended construction logging.getLogger(__name__). That's because in a module, __name__ is the module's name in the Python package namespace.

Handler Objects

Handlers have the following attributes and methods. Note that :class:`Handler` is never instantiated directly; this class acts as a base for more useful subclasses. However, the :meth:`__init__` method in subclasses needs to call :meth:`Handler.__init__`.

For a list of handlers included as standard, see :mod:`logging.handlers`.

Formatter Objects

:class:`Formatter` objects have the following attributes and methods. They are responsible for converting a :class:`LogRecord` to (usually) a string which can be interpreted by either a human or an external system. The base :class:`Formatter` allows a formatting string to be specified. If none is supplied, the default value of '%(message)s' is used.

A Formatter can be initialized with a format string which makes use of knowledge of the :class:`LogRecord` attributes - such as the default value mentioned above making use of the fact that the user's message and arguments are pre-formatted into a :class:`LogRecord`'s message attribute. This format string contains standard Python %-style mapping keys. See section :ref:`old-string-formatting` for more information on string formatting.

The useful mapping keys in a :class:`LogRecord` are given in the section on :ref:`logrecord-attributes`.

Returns a new instance of the :class:`Formatter` class. The instance is initialized with a format string for the message as a whole, as well as a format string for the date/time portion of a message. If no fmt is specified, '%(message)s' is used. If no datefmt is specified, the ISO8601 date format is used.

The style parameter can be one of '%', '{' or '$' and determines how the format string will be merged with its data: using one of %-formatting, :meth:`str.format` or :class:`string.Template`.

Filter Objects

Filters can be used by Handlers and Loggers for more sophisticated filtering than is provided by levels. The base filter class only allows events which are below a certain point in the logger hierarchy. For example, a filter initialized with 'A.B' will allow events logged by loggers 'A.B', 'A.B.C', 'A.B.C.D', 'A.B.D' etc. but not 'A.BB', 'B.A.B' etc. If initialized with the empty string, all events are passed.

Returns an instance of the :class:`Filter` class. If name is specified, it names a logger which, together with its children, will have its events allowed through the filter. If name is the empty string, allows every event.

Note that filters attached to handlers are consulted before an event is emitted by the handler, whereas filters attached to loggers are consulted whenever an event is logged (using :meth:`debug`, :meth:`info`, etc.), before sending an event to handlers. This means that events which have been generated by descendant loggers will not be filtered by a logger's filter setting, unless the filter has also been applied to those descendant loggers.

You don't actually need to subclass Filter: you can pass any instance which has a filter method with the same semantics.

Although filters are used primarily to filter records based on more sophisticated criteria than levels, they get to see every record which is processed by the handler or logger they're attached to: this can be useful if you want to do things like counting how many records were processed by a particular logger or handler, or adding, changing or removing attributes in the LogRecord being processed. Obviously changing the LogRecord needs to be done with some care, but it does allow the injection of contextual information into logs (see :ref:`filters-contextual`).

LogRecord Objects

:class:`LogRecord` instances are created automatically by the :class:`Logger` every time something is logged, and can be created manually via :func:`makeLogRecord` (for example, from a pickled event received over the wire).

Contains all the information pertinent to the event being logged.

The primary information is passed in :attr:`msg` and :attr:`args`, which are combined using msg % args to create the :attr:`message` field of the record.

param name:The name of the logger used to log the event represented by this LogRecord. Note that this name will always have this value, even though it may be emitted by a handler attached to a different (ancestor) logger.
param level:The numeric level of the logging event (one of DEBUG, INFO etc.) Note that this is converted to two attributes of the LogRecord: levelno for the numeric value and levelname for the corresponding level name.
param pathname:The full pathname of the source file where the logging call was made.
param lineno:The line number in the source file where the logging call was made.
param msg:The event description message, possibly a format string with placeholders for variable data.
param args:Variable data to merge into the msg argument to obtain the event description.
param exc_info:An exception tuple with the current exception information, or None if no exception information is available.
param func:The name of the function or method from which the logging call was invoked.
param sinfo:A text string representing stack information from the base of the stack in the current thread, up to the logging call.

This functionality can be used to inject your own values into a LogRecord at creation time. You can use the following pattern:

old_factory = logging.getLogRecordFactory()

def record_factory(*args, **kwargs):
    record = old_factory(*args, **kwargs)
    record.custom_attribute = 0xdecafbad
    return record


With this pattern, multiple factories could be chained, and as long as they don't overwrite each other's attributes or unintentionally overwrite the standard attributes listed above, there should be no surprises.

LogRecord attributes

The LogRecord has a number of attributes, most of which are derived from the parameters to the constructor. (Note that the names do not always correspond exactly between the LogRecord constructor parameters and the LogRecord attributes.) These attributes can be used to merge data from the record into the format string. The following table lists (in alphabetical order) the attribute names, their meanings and the corresponding placeholder in a %-style format string.

If you are using {}-formatting (:func:`str.format`), you can use {attrname} as the placeholder in the format string. If you are using $-formatting (:class:`string.Template`), use the form ${attrname}. In both cases, of course, replace attrname with the actual attribute name you want to use.

In the case of {}-formatting, you can specify formatting flags by placing them after the attribute name, separated from it with a colon. For example: a placeholder of {msecs:03d} would format a millisecond value of 4 as 004. Refer to the :meth:`str.format` documentation for full details on the options available to you.

Attribute name Format Description
args You shouldn't need to format this yourself. The tuple of arguments merged into msg to produce message.
asctime %(asctime)s Human-readable time when the :class:`LogRecord` was created. By default this is of the form '2003-07-08 16:49:45,896' (the numbers after the comma are millisecond portion of the time).
created %(created)f Time when the :class:`LogRecord` was created (as returned by :func:`time.time`).
exc_info You shouldn't need to format this yourself. Exception tuple (à la sys.exc_info) or, if no exception has occurred, None.
filename %(filename)s Filename portion of pathname.
funcName %(funcName)s Name of function containing the logging call.
levelname %(levelname)s Text logging level for the message ('DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL').
levelno %(levelno)s Numeric logging level for the message (:const:`DEBUG`, :const:`INFO`, :const:`WARNING`, :const:`ERROR`, :const:`CRITICAL`).
lineno %(lineno)d Source line number where the logging call was issued (if available).
module %(module)s Module (name portion of filename).
msecs %(msecs)d Millisecond portion of the time when the :class:`LogRecord` was created.
message %(message)s The logged message, computed as msg % args. This is set when :meth:`Formatter.format` is invoked.
msg You shouldn't need to format this yourself. The format string passed in the original logging call. Merged with args to produce message, or an arbitrary object (see :ref:`arbitrary-object-messages`).
name %(name)s Name of the logger used to log the call.
pathname %(pathname)s Full pathname of the source file where the logging call was issued (if available).
process %(process)d Process ID (if available).
processName %(processName)s Process name (if available).
relativeCreated %(relativeCreated)d Time in milliseconds when the LogRecord was created, relative to the time the logging module was loaded.
stack_info You shouldn't need to format this yourself. Stack frame information (where available) from the bottom of the stack in the current thread, up to and including the stack frame of the logging call which resulted in the creation of this record.
thread %(thread)d Thread ID (if available).
threadName %(threadName)s Thread name (if available).

LoggerAdapter Objects

:class:`LoggerAdapter` instances are used to conveniently pass contextual information into logging calls. For a usage example , see the section on :ref:`adding contextual information to your logging output <context-info>`.

Returns an instance of :class:`LoggerAdapter` initialized with an underlying :class:`Logger` instance and a dict-like object.

In addition to the above, :class:`LoggerAdapter` supports the following methods of :class:`Logger`, i.e. :meth:`debug`, :meth:`info`, :meth:`warning`, :meth:`error`, :meth:`exception`, :meth:`critical`, :meth:`log`, :meth:`isEnabledFor`, :meth:`getEffectiveLevel`, :meth:`setLevel`, :meth:`hasHandlers`. These methods have the same signatures as their counterparts in :class:`Logger`, so you can use the two types of instances interchangeably.

Thread Safety

The logging module is intended to be thread-safe without any special work needing to be done by its clients. It achieves this though using threading locks; there is one lock to serialize access to the module's shared data, and each handler also creates a lock to serialize access to its underlying I/O.

If you are implementing asynchronous signal handlers using the :mod:`signal` module, you may not be able to use logging from within such handlers. This is because lock implementations in the :mod:`threading` module are not always re-entrant, and so cannot be invoked from such signal handlers.

Module-Level Functions

In addition to the classes described above, there are a number of module- level functions.

Module-Level Attributes

Integration with the warnings module

The :func:`captureWarnings` function can be used to integrate :mod:`logging` with the :mod:`warnings` module.