Edit File - File Manager

Edit File: logging.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 
 <title>15.6. logging — Logging facility for Python &mdash; Python v2.6.6 documentation</title>
 <link rel="stylesheet" href="../_static/default.css" type="text/css" />
 <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
 <script type="text/javascript">
 var DOCUMENTATION_OPTIONS = {
 URL_ROOT: '../',
 VERSION: '2.6.6',
 COLLAPSE_MODINDEX: false,
 FILE_SUFFIX: '.html',
 HAS_SOURCE: true
 };
 </script>
 <script type="text/javascript" src="../_static/jquery.js"></script>
 <script type="text/javascript" src="../_static/doctools.js"></script>
 <link rel="search" type="application/opensearchdescription+xml"
 title="Search within Python v2.6.6 documentation"
 href="../_static/opensearch.xml"/>
 <link rel="author" title="About these documents" href="../about.html" />
 <link rel="copyright" title="Copyright" href="../copyright.html" />
 <link rel="top" title="Python v2.6.6 documentation" href="../index.html" />
 <link rel="up" title="15. Generic Operating System Services" href="allos.html" />
 <link rel="next" title="15.7. getpass — Portable password input" href="getpass.html" />
 <link rel="prev" title="15.5. getopt — Parser for command line options" href="getopt.html" />
 <link rel="shortcut icon" type="image/png" href="../_static/py.png" />

</head>
 <body>
 <div class="related">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="../genindex.html" title="General Index"
 accesskey="I">index</a></li>
 <li class="right" >
 <a href="../modindex.html" title="Global Module Index"
 accesskey="M">modules</a> |</li>
 <li class="right" >
 <a href="getpass.html" title="15.7. getpass — Portable password input"
 accesskey="N">next</a> |</li>
 <li class="right" >
 <a href="getopt.html" title="15.5. getopt — Parser for command line options"
 accesskey="P">previous</a> |</li>
 <li><img src="../_static/py.png" alt=""
 style="vertical-align: middle; margin-top: -1px"/></li>
 <li><a href="../index.html">Python v2.6.6 documentation</a> &raquo;</li>

<li><a href="index.html" >The Python Standard Library</a> &raquo;</li>
 <li><a href="allos.html" accesskey="U">15. Generic Operating System Services</a> &raquo;</li> 
 </ul>
 </div>

<div class="document">
 <div class="documentwrapper">
 <div class="bodywrapper">
 <div class="body">
 
 <div class="section" id="module-logging">
<h1>15.6. <tt class="xref docutils literal">logging</tt> &#8212; Logging facility for Python<a class="headerlink" href="#module-logging" title="Permalink to this headline">¶</a></h1>

New in version 2.3.
This module defines functions and classes which implement a flexible error
logging system for applications.
Logging is performed by calling methods on instances of the <tt class="xref docutils literal">Logger</tt>
class (hereafter called loggers). Each instance has a name, and they are
conceptually arranged in a namespace hierarchy using dots (periods) as
separators. For example, a logger named &#8220;scan&#8221; is the parent of loggers
&#8220;scan.text&#8221;, &#8220;scan.html&#8221; and &#8220;scan.pdf&#8221;. Logger names can be anything you want,
and indicate the area of an application in which a logged message originates.
Logged messages also have levels of importance associated with them. The default
levels provided are <tt class="xref docutils literal">DEBUG</tt>, <tt class="xref docutils literal">INFO</tt>, <tt class="xref docutils literal">WARNING</tt>,
<tt class="xref docutils literal">ERROR</tt> and <tt class="xref docutils literal">CRITICAL</tt>. As a convenience, you indicate the
importance of a logged message by calling an appropriate method of
<tt class="xref docutils literal">Logger</tt>. The methods are <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>, <a title="logging.info" class="reference internal" href="#logging.info"><tt class="xref docutils literal">info()</tt></a>, <a title="logging.warning" class="reference internal" href="#logging.warning"><tt class="xref docutils literal">warning()</tt></a>,
<a title="logging.error" class="reference internal" href="#logging.error"><tt class="xref docutils literal">error()</tt></a> and <a title="logging.critical" class="reference internal" href="#logging.critical"><tt class="xref docutils literal">critical()</tt></a>, which mirror the default levels. You are not
constrained to use these levels: you can specify your own and use a more general
<tt class="xref docutils literal">Logger</tt> method, <a title="logging.log" class="reference internal" href="#logging.log"><tt class="xref docutils literal">log()</tt></a>, which takes an explicit level argument.
<div class="section" id="logging-tutorial">
<h2>15.6.1. Logging tutorial<a class="headerlink" href="#logging-tutorial" title="Permalink to this headline">¶</a></h2>
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 messages from third-party modules.
It is, of course, possible to log messages with different verbosity levels or to
different destinations. Support for writing log messages to files, HTTP
GET/POST locations, email via SMTP, generic sockets, or OS-specific logging
mechanisms are all supported by the standard module. You can also create your
own log destination class if you have special requirements not met by any of the
built-in classes.
<div class="section" id="simple-examples">
<h3>15.6.1.1. Simple examples<a class="headerlink" href="#simple-examples" title="Permalink to this headline">¶</a></h3>
Most applications are probably going to want to log to a file, so let&#8217;s start
with that case. Using the <a title="logging.basicConfig" class="reference internal" href="#logging.basicConfig"><tt class="xref docutils literal">basicConfig()</tt></a> function, we can set up the
default handler so that debug messages are written to a file (in the example,
we assume that you have the appropriate permissions to create a file called
example.log in the current directory):
<div class="highlight-python"><div class="highlight"><pre>import logging
LOG_FILENAME = &#39;example.log&#39;
logging.basicConfig(filename=LOG_FILENAME,level=logging.DEBUG)

logging.debug(&#39;This message should go to the log file&#39;)
</pre></div>
</div>
And now if we open the file and look at what we have, we should find the log
message:
<div class="highlight-python"><pre>DEBUG:root:This message should go to the log file</pre>
</div>
If you run the script repeatedly, the additional log messages are appended to
the file. To create a new file each time, you can pass a filemode argument to
<a title="logging.basicConfig" class="reference internal" href="#logging.basicConfig"><tt class="xref docutils literal">basicConfig()</tt></a> with a value of <tt class="docutils literal">'w'</tt>. Rather than managing the file size
yourself, though, it is simpler to use a <a title="logging.RotatingFileHandler" class="reference internal" href="#logging.RotatingFileHandler"><tt class="xref docutils literal">RotatingFileHandler</tt></a>:
<div class="highlight-python"><div class="highlight"><pre>import glob
import logging
import logging.handlers

LOG_FILENAME = &#39;logging_rotatingfile_example.out&#39;

# Set up a specific logger with our desired output level
my_logger = logging.getLogger(&#39;MyLogger&#39;)
my_logger.setLevel(logging.DEBUG)

# Add the log message handler to the logger
handler = logging.handlers.RotatingFileHandler(
 LOG_FILENAME, maxBytes=20, backupCount=5)

my_logger.addHandler(handler)

# Log some messages
for i in range(20):
 my_logger.debug(&#39;i = %d&#39; % i)

# See what files are created
logfiles = glob.glob(&#39;%s*&#39; % LOG_FILENAME)

for filename in logfiles:
 print filename
</pre></div>
</div>
The result should be 6 separate files, each with part of the log history for the
application:
<div class="highlight-python"><pre>logging_rotatingfile_example.out
logging_rotatingfile_example.out.1
logging_rotatingfile_example.out.2
logging_rotatingfile_example.out.3
logging_rotatingfile_example.out.4
logging_rotatingfile_example.out.5</pre>
</div>
The most current file is always <tt class="docutils literal">logging_rotatingfile_example.out</tt>,
and each time it reaches the size limit it is renamed with the suffix
<tt class="docutils literal">.1</tt>. Each of the existing backup files is renamed to increment the suffix
(<tt class="docutils literal">.1</tt> becomes <tt class="docutils literal">.2</tt>, etc.) and the <tt class="docutils literal">.6</tt> file is erased.
Obviously this example sets the log length much much too small as an extreme
example. You would want to set maxBytes to an appropriate value.
Another useful feature of the logging API is the ability to produce different
messages at different log levels. This allows you to instrument your code with
debug messages, for example, but turning the log level down so that those debug
messages are not written for your production system. The default levels are
<tt class="docutils literal">NOTSET</tt>, <tt class="docutils literal">DEBUG</tt>, <tt class="docutils literal">INFO</tt>, <tt class="docutils literal">WARNING</tt>, <tt class="docutils literal">ERROR</tt> and <tt class="docutils literal">CRITICAL</tt>.
The logger, handler, and log message call each specify a level. The log message
is only emitted if the handler and logger are configured to emit messages of
that level or lower. For example, if a message is <tt class="docutils literal">CRITICAL</tt>, and the logger
is set to <tt class="docutils literal">ERROR</tt>, the message is emitted. If a message is a <tt class="docutils literal">WARNING</tt>, and
the logger is set to produce only <tt class="docutils literal">ERROR</tt>s, the message is not emitted:
<div class="highlight-python"><div class="highlight"><pre>import logging
import sys

LEVELS = {&#39;debug&#39;: logging.DEBUG,
 &#39;info&#39;: logging.INFO,
 &#39;warning&#39;: logging.WARNING,
 &#39;error&#39;: logging.ERROR,
 &#39;critical&#39;: logging.CRITICAL}

if len(sys.argv) &gt; 1:
 level_name = sys.argv[1]
 level = LEVELS.get(level_name, logging.NOTSET)
 logging.basicConfig(level=level)

logging.debug(&#39;This is a debug message&#39;)
logging.info(&#39;This is an info message&#39;)
logging.warning(&#39;This is a warning message&#39;)
logging.error(&#39;This is an error message&#39;)
logging.critical(&#39;This is a critical error message&#39;)
</pre></div>
</div>
Run the script with an argument like &#8216;debug&#8217; or &#8216;warning&#8217; to see which messages
show up at different levels:
<div class="highlight-python"><pre>$ python logging_level_example.py debug
DEBUG:root:This is a debug message
INFO:root:This is an info message
WARNING:root:This is a warning message
ERROR:root:This is an error message
CRITICAL:root:This is a critical error message

$ python logging_level_example.py info
INFO:root:This is an info message
WARNING:root:This is a warning message
ERROR:root:This is an error message
CRITICAL:root:This is a critical error message</pre>
</div>
You will notice that these log messages all have <tt class="docutils literal">root</tt> embedded in them. The
logging module supports a hierarchy of loggers with different names. An easy
way to tell where a specific log message comes from is to use a separate logger
object for each of your modules. Each new logger &#8220;inherits&#8221; the configuration
of its parent, and log messages sent to a logger include the name of that
logger. Optionally, each logger can be configured differently, so that messages
from different modules are handled in different ways. Let&#8217;s look at a simple
example of how to log from different modules so it is easy to trace the source
of the message:
<div class="highlight-python"><div class="highlight"><pre>import logging

logger1 = logging.getLogger(&#39;package1.module1&#39;)
logger2 = logging.getLogger(&#39;package2.module2&#39;)

logger1.warning(&#39;This message comes from one module&#39;)
logger2.warning(&#39;And this message comes from another module&#39;)
</pre></div>
</div>
And the output:
<div class="highlight-python"><pre>$ python logging_modules_example.py
WARNING:package1.module1:This message comes from one module
WARNING:package2.module2:And this message comes from another module</pre>
</div>
There are many more options for configuring logging, including different log
message formatting options, having messages delivered to multiple destinations,
and changing the configuration of a long-running application on the fly using a
socket interface. All of these options are covered in depth in the library
module documentation.
</div>
<div class="section" id="loggers">
<h3>15.6.1.2. Loggers<a class="headerlink" href="#loggers" title="Permalink to this headline">¶</a></h3>
The logging library takes a modular approach and offers the several categories
of components: loggers, handlers, filters, and formatters. Loggers expose the
interface that application code directly uses. Handlers send the log records to
the appropriate destination. Filters provide a finer grained facility for
determining which log records to send on to a handler. Formatters specify the
layout of the resultant log record.
<tt class="xref docutils literal">Logger</tt> objects have a threefold job. First, they expose several
methods to application code so that applications can log messages at runtime.
Second, logger objects determine which log messages to act upon based upon
severity (the default filtering facility) or filter objects. Third, logger
objects pass along relevant log messages to all interested log handlers.
The most widely used methods on logger objects fall into two categories:
configuration and message sending.
<ul class="simple">
<li><a title="logging.Logger.setLevel" class="reference internal" href="#logging.Logger.setLevel"><tt class="xref docutils literal">Logger.setLevel()</tt></a> specifies the lowest-severity log message a logger
will handle, where debug is the lowest built-in severity level and critical is
the highest built-in severity. For example, if the severity level is info,
the logger will handle only info, warning, error, and critical messages and
will ignore debug messages.</li>
<li><a title="logging.Logger.addFilter" class="reference internal" href="#logging.Logger.addFilter"><tt class="xref docutils literal">Logger.addFilter()</tt></a> and <a title="logging.Logger.removeFilter" class="reference internal" href="#logging.Logger.removeFilter"><tt class="xref docutils literal">Logger.removeFilter()</tt></a> add and remove filter
objects from the logger object. This tutorial does not address filters.</li>
</ul>
With the logger object configured, the following methods create log messages:
<ul class="simple">
<li><a title="logging.Logger.debug" class="reference internal" href="#logging.Logger.debug"><tt class="xref docutils literal">Logger.debug()</tt></a>, <a title="logging.Logger.info" class="reference internal" href="#logging.Logger.info"><tt class="xref docutils literal">Logger.info()</tt></a>, <a title="logging.Logger.warning" class="reference internal" href="#logging.Logger.warning"><tt class="xref docutils literal">Logger.warning()</tt></a>,
<a title="logging.Logger.error" class="reference internal" href="#logging.Logger.error"><tt class="xref docutils literal">Logger.error()</tt></a>, and <a title="logging.Logger.critical" class="reference internal" href="#logging.Logger.critical"><tt class="xref docutils literal">Logger.critical()</tt></a> all create log records with
a message and a level that corresponds to their respective method names. The
message is actually a format string, which may contain the standard string
substitution syntax of <tt class="xref docutils literal">%s</tt>, <tt class="xref docutils literal">%d</tt>, <tt class="xref docutils literal">%f</tt>, and so on. The
rest of their arguments is a list of objects that correspond with the
substitution fields in the message. With regard to <tt class="xref docutils literal">**kwargs</tt>, the
logging methods care only about a keyword of <tt class="xref docutils literal">exc_info</tt> and use it to
determine whether to log exception information.</li>
<li><a title="logging.Logger.exception" class="reference internal" href="#logging.Logger.exception"><tt class="xref docutils literal">Logger.exception()</tt></a> creates a log message similar to
<a title="logging.Logger.error" class="reference internal" href="#logging.Logger.error"><tt class="xref docutils literal">Logger.error()</tt></a>. The difference is that <a title="logging.Logger.exception" class="reference internal" href="#logging.Logger.exception"><tt class="xref docutils literal">Logger.exception()</tt></a> dumps a
stack trace along with it. Call this method only from an exception handler.</li>
<li><a title="logging.Logger.log" class="reference internal" href="#logging.Logger.log"><tt class="xref docutils literal">Logger.log()</tt></a> takes a log level as an explicit argument. This is a
little more verbose for logging messages than using the log level convenience
methods listed above, but this is how to log at custom log levels.</li>
</ul>
<a title="logging.getLogger" class="reference internal" href="#logging.getLogger"><tt class="xref docutils literal">getLogger()</tt></a> returns a reference to a logger instance with the specified
name if it is provided, or <tt class="docutils literal">root</tt> if not. The names are period-separated
hierarchical structures. Multiple calls to <a title="logging.getLogger" class="reference internal" href="#logging.getLogger"><tt class="xref docutils literal">getLogger()</tt></a> with the same name
will return a reference to the same logger object. 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 <tt class="docutils literal">foo</tt>, loggers with names of
<tt class="docutils literal">foo.bar</tt>, <tt class="docutils literal">foo.bar.baz</tt>, and <tt class="docutils literal">foo.bam</tt> are all descendants of <tt class="docutils literal">foo</tt>.
Child loggers propagate messages up to the handlers associated with their
ancestor loggers. Because of this, it is unnecessary to define and configure
handlers for all the loggers an application uses. It is sufficient to
configure handlers for a top-level logger and create child loggers as needed.
</div>
<div class="section" id="handlers">
<h3>15.6.1.3. Handlers<a class="headerlink" href="#handlers" title="Permalink to this headline">¶</a></h3>
<tt class="xref docutils literal">Handler</tt> objects are responsible for dispatching the appropriate log
messages (based on the log messages&#8217; severity) to the handler&#8217;s specified
destination. Logger objects can add zero or more handler objects to themselves
with an <tt class="xref docutils literal">addHandler()</tt> method. As an example scenario, an application may
want to send all log messages to a log file, all log messages of error or higher
to stdout, and all messages of critical to an email address. This scenario
requires three individual handlers where each handler is responsible for sending
messages of a specific severity to a specific location.
The standard library includes quite a few handler types; this tutorial uses only
<a title="logging.StreamHandler" class="reference internal" href="#logging.StreamHandler"><tt class="xref docutils literal">StreamHandler</tt></a> and <a title="logging.FileHandler" class="reference internal" href="#logging.FileHandler"><tt class="xref docutils literal">FileHandler</tt></a> in its examples.
There are very few methods in a handler for application developers to concern
themselves with. The only handler methods that seem relevant for application
developers who are using the built-in handler objects (that is, not creating
custom handlers) are the following configuration methods:
<ul class="simple">
<li>The <a title="logging.Handler.setLevel" class="reference internal" href="#logging.Handler.setLevel"><tt class="xref docutils literal">Handler.setLevel()</tt></a> method, just as in logger objects, specifies the
lowest severity that will be dispatched to the appropriate destination. Why
are there two <tt class="xref docutils literal">setLevel()</tt> methods? The level set in the logger
determines which severity of messages it will pass to its handlers. The level
set in each handler determines which messages that handler will send on.</li>
<li><tt class="xref docutils literal">setFormatter()</tt> selects a Formatter object for this handler to use.</li>
<li><tt class="xref docutils literal">addFilter()</tt> and <tt class="xref docutils literal">removeFilter()</tt> respectively configure and
deconfigure filter objects on handlers.</li>
</ul>
Application code should not directly instantiate and use instances of
<tt class="xref docutils literal">Handler</tt>. Instead, the <tt class="xref docutils literal">Handler</tt> class is a base class that
defines the interface that all handlers should have and establishes some
default behavior that child classes can use (or override).
</div>
<div class="section" id="formatters">
<h3>15.6.1.4. Formatters<a class="headerlink" href="#formatters" title="Permalink to this headline">¶</a></h3>
Formatter objects configure the final order, structure, and contents of the log
message. Unlike the base <tt class="xref docutils literal">logging.Handler</tt> class, application code may
instantiate formatter classes, although you could likely subclass the formatter
if your application needs special behavior. The constructor takes two optional
arguments: a message format string and a date format string. If there is no
message format string, the default is to use the raw message. If there is no
date format string, the default date format is:
<div class="highlight-python"><pre>%Y-%m-%d %H:%M:%S</pre>
</div>
with the milliseconds tacked on at the end.
The message format string uses <tt class="docutils literal">%(&lt;dictionary key&gt;)s</tt> styled string
substitution; the possible keys are documented in <a class="reference internal" href="#formatter">Formatter Objects</a>.
The following message format string will log the time in a human-readable
format, the severity of the message, and the contents of the message, in that
order:
<div class="highlight-python"><div class="highlight"><pre>&quot;%(asctime)s - %(levelname)s - %(message)s&quot;
</pre></div>
</div>
</div>
<div class="section" id="configuring-logging">
<h3>15.6.1.5. Configuring Logging<a class="headerlink" href="#configuring-logging" title="Permalink to this headline">¶</a></h3>
Programmers can configure logging either by creating loggers, handlers, and
formatters explicitly in a main module with the configuration methods listed
above (using Python code), or by creating a logging config file. The following
code is an example of configuring a very simple logger, a console handler, and a
simple formatter in a Python module:
<div class="highlight-python"><div class="highlight"><pre>import logging

# create logger
logger = logging.getLogger(&quot;simple_example&quot;)
logger.setLevel(logging.DEBUG)
# create console handler and set level to debug
ch = logging.StreamHandler()
ch.setLevel(logging.DEBUG)
# create formatter
formatter = logging.Formatter(&quot;%(asctime)s - %(name)s - %(levelname)s - %(message)s&quot;)
# add formatter to ch
ch.setFormatter(formatter)
# add ch to logger
logger.addHandler(ch)

logging.config.fileConfig(&quot;logging.conf&quot;)

[handlers]
keys=consoleHandler

[formatters]
keys=simpleFormatter

[logger_root]
level=DEBUG
handlers=consoleHandler

[logger_simpleExample]
level=DEBUG
handlers=consoleHandler
qualname=simpleExample
propagate=0

[handler_consoleHandler]
class=StreamHandler
level=DEBUG
formatter=simpleFormatter
args=(sys.stdout,)

[formatter_simpleFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=</pre>
</div>
The output is nearly identical to that of the non-config-file-based example:
<div class="highlight-python"><pre>$ python simple_logging_config.py
2005-03-19 15:38:55,977 - simpleExample - DEBUG - debug message
2005-03-19 15:38:55,979 - simpleExample - INFO - info message
2005-03-19 15:38:56,054 - simpleExample - WARNING - warn message
2005-03-19 15:38:56,055 - simpleExample - ERROR - error message
2005-03-19 15:38:56,130 - simpleExample - CRITICAL - critical message</pre>
</div>
You can see that the config file approach has a few advantages over the Python
code approach, mainly separation of configuration and code and the ability of
noncoders to easily modify the logging properties.
</div>
<div class="section" id="configuring-logging-for-a-library">
<h3>15.6.1.6. Configuring Logging for a Library<a class="headerlink" href="#configuring-logging-for-a-library" title="Permalink to this headline">¶</a></h3>
When developing a library which uses logging, some consideration needs to be
given to its configuration. If the using application does not use logging, and
library code makes logging calls, then a one-off message &#8220;No handlers could be
found for logger X.Y.Z&#8221; is printed to the console. This message is intended
to catch mistakes in logging configuration, but will confuse an application
developer who is not aware of logging by the library.
In addition to documenting how a library uses logging, a good way to configure
library logging so that it does not cause a spurious message is to add a
handler which does nothing. This avoids the message being printed, since a
handler will be found: it just doesn&#8217;t produce any output. If the library user
configures logging for application use, presumably that configuration will add
some handlers, and if levels are suitably configured then logging calls made
in library code will send output to those handlers, as normal.
A do-nothing handler can be simply defined as follows:
<div class="highlight-python"><div class="highlight"><pre>import logging

class NullHandler(logging.Handler):
 def emit(self, record):
 pass
</pre></div>
</div>
An instance of this handler should be added to the top-level logger of the
logging namespace used by the library. If all logging by a library foo is
done using loggers with names matching &#8220;foo.x.y&#8221;, then the code:
<div class="highlight-python"><div class="highlight"><pre>import logging

h = NullHandler()
logging.getLogger(&quot;foo&quot;).addHandler(h)
</pre></div>
</div>
should have the desired effect. If an organisation produces a number of
libraries, then the logger name specified can be &#8220;orgname.foo&#8221; rather than
just &#8220;foo&#8221;.
</div>
</div>
<div class="section" id="logging-levels">
<h2>15.6.2. Logging Levels<a class="headerlink" href="#logging-levels" title="Permalink to this headline">¶</a></h2>
The numeric values of logging levels are given in the following table. These are
primarily of interest if you want to define your own levels, and need them to
have specific values relative to the predefined levels. If you define a level
with the same numeric value, it overwrites the predefined value; the predefined
name is lost.
<table border="1" class="docutils">
<colgroup>
<col width="48%" />
<col width="52%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Level</th>
<th class="head">Numeric value</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">CRITICAL</tt></td>
<td>50</td>
</tr>
<tr><td><tt class="docutils literal">ERROR</tt></td>
<td>40</td>
</tr>
<tr><td><tt class="docutils literal">WARNING</tt></td>
<td>30</td>
</tr>
<tr><td><tt class="docutils literal">INFO</tt></td>
<td>20</td>
</tr>
<tr><td><tt class="docutils literal">DEBUG</tt></td>
<td>10</td>
</tr>
<tr><td><tt class="docutils literal">NOTSET</tt></td>
<td>0</td>
</tr>
</tbody>
</table>
Levels can also be associated with loggers, being set either by the developer or
through loading a saved logging configuration. When a logging method is called
on a logger, the logger compares its own level with the level associated with
the method call. If the logger&#8217;s level is higher than the method call&#8217;s, no
logging message is actually generated. This is the basic mechanism controlling
the verbosity of logging output.
Logging messages are encoded as instances of the <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> class. When
a logger decides to actually log an event, a <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instance is
created from the logging message.
Logging messages are subjected to a dispatch mechanism through the use of
handlers, which are instances of subclasses of the <tt class="xref docutils literal">Handler</tt>
class. Handlers are responsible for ensuring that a logged message (in the form
of a <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a>) ends up in a particular location (or set of locations)
which is useful for the target audience for that message (such as end users,
support desk staff, system administrators, developers). Handlers are passed
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instances intended for particular destinations. Each logger
can have zero, one or more handlers associated with it (via the
<tt class="xref docutils literal">addHandler()</tt> method of <tt class="xref docutils literal">Logger</tt>). In addition to any handlers
directly associated with a logger, all handlers associated with all ancestors
of the logger are called to dispatch the message (unless the propagate flag
for a logger is set to a false value, at which point the passing to ancestor
handlers stops).
Just as for loggers, handlers can have levels associated with them. A handler&#8217;s
level acts as a filter in the same way as a logger&#8217;s level does. If a handler
decides to actually dispatch an event, the <tt class="xref docutils literal">emit()</tt> method is used to send
the message to its destination. Most user-defined subclasses of <tt class="xref docutils literal">Handler</tt>
will need to override this <tt class="xref docutils literal">emit()</tt>.
</div>
<div class="section" id="useful-handlers">
<h2>15.6.3. Useful Handlers<a class="headerlink" href="#useful-handlers" title="Permalink to this headline">¶</a></h2>
In addition to the base <tt class="xref docutils literal">Handler</tt> class, many useful subclasses are
provided:
<ol class="arabic simple">
<li><a class="reference internal" href="#stream-handler">StreamHandler</a> instances send error messages to streams (file-like
objects).</li>
<li><a class="reference internal" href="#file-handler">FileHandler</a> instances send error messages to disk files.</li>
<li><tt class="xref docutils literal">BaseRotatingHandler</tt> is the base class for handlers that
rotate log files at a certain point. It is not meant to be instantiated
directly. Instead, use <a class="reference internal" href="#rotating-file-handler">RotatingFileHandler</a> or
<a class="reference internal" href="#timed-rotating-file-handler">TimedRotatingFileHandler</a>.</li>
<li><a class="reference internal" href="#rotating-file-handler">RotatingFileHandler</a> instances send error messages to disk
files, with support for maximum log file sizes and log file rotation.</li>
<li><a class="reference internal" href="#timed-rotating-file-handler">TimedRotatingFileHandler</a> instances send error messages to
disk files, rotating the log file at certain timed intervals.</li>
<li><a class="reference internal" href="#socket-handler">SocketHandler</a> instances send error messages to TCP/IP
sockets.</li>
<li><a class="reference internal" href="#datagram-handler">DatagramHandler</a> instances send error messages to UDP
sockets.</li>
<li><a class="reference internal" href="#smtp-handler">SMTPHandler</a> instances send error messages to a designated
email address.</li>
<li><a class="reference internal" href="#syslog-handler">SysLogHandler</a> instances send error messages to a Unix
syslog daemon, possibly on a remote machine.</li>
<li><a class="reference internal" href="#nt-eventlog-handler">NTEventLogHandler</a> instances send error messages to a
Windows NT/2000/XP event log.</li>
<li><a class="reference internal" href="#memory-handler">MemoryHandler</a> instances send error messages to a buffer
in memory, which is flushed whenever specific criteria are met.</li>
<li><a class="reference internal" href="#http-handler">HTTPHandler</a> instances send error messages to an HTTP
server using either <tt class="docutils literal">GET</tt> or <tt class="docutils literal">POST</tt> semantics.</li>
<li><a class="reference internal" href="#watched-file-handler">WatchedFileHandler</a> instances watch the file they are
logging to. If the file changes, it is closed and reopened using the file
name. This handler is only useful on Unix-like systems; Windows does not
support the underlying mechanism used.</li>
</ol>
The <a title="logging.StreamHandler" class="reference internal" href="#logging.StreamHandler"><tt class="xref docutils literal">StreamHandler</tt></a> and <a title="logging.FileHandler" class="reference internal" href="#logging.FileHandler"><tt class="xref docutils literal">FileHandler</tt></a>
classes are defined in the core logging package. The other handlers are
defined in a sub- module, <tt class="xref docutils literal">logging.handlers</tt>. (There is also another
sub-module, <tt class="xref docutils literal">logging.config</tt>, for configuration functionality.)
Logged messages are formatted for presentation through instances of the
<a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> class. They are initialized with a format string suitable for
use with the % operator and a dictionary.
For formatting multiple messages in a batch, instances of
<tt class="xref docutils literal">BufferingFormatter</tt> can be used. In addition to the format string (which
is applied to each message in the batch), there is provision for header and
trailer format strings.
When filtering based on logger level and/or handler level is not enough,
instances of <a title="logging.Filter" class="reference internal" href="#logging.Filter"><tt class="xref docutils literal">Filter</tt></a> can be added to both <tt class="xref docutils literal">Logger</tt> and
<tt class="xref docutils literal">Handler</tt> instances (through their <tt class="xref docutils literal">addFilter()</tt> method). Before
deciding to process a message further, both loggers and handlers consult all
their filters for permission. If any filter returns a false value, the message
is not processed further.
The basic <a title="logging.Filter" class="reference internal" href="#logging.Filter"><tt class="xref docutils literal">Filter</tt></a> functionality allows filtering by specific logger
name. If this feature is used, messages sent to the named logger and its
children are allowed through the filter, and all others dropped.
</div>
<div class="section" id="module-level-functions">
<h2>15.6.4. Module-Level Functions<a class="headerlink" href="#module-level-functions" title="Permalink to this headline">¶</a></h2>
In addition to the classes described above, there are a number of module- level
functions.
<dl class="function">
<dt id="logging.getLogger">
<tt class="descclassname">logging.</tt><tt class="descname">getLogger</tt><big>(</big>[name]<big>)</big><a class="headerlink" href="#logging.getLogger" title="Permalink to this definition">¶</a></dt>
<dd>Return a logger with the specified name or, if no name is specified, return a
logger which is the root logger of the hierarchy. If specified, the name is
typically a dot-separated hierarchical name like &#8220;a&#8221;, &#8220;a.b&#8221; or &#8220;a.b.c.d&#8221;.
Choice of these names is entirely up to the developer who is using logging.
All calls to this function with a given name return the same logger instance.
This means that logger instances never need to be passed between different parts
of an application.
</dd></dl>

<dl class="function">
<dt id="logging.getLoggerClass">
<tt class="descclassname">logging.</tt><tt class="descname">getLoggerClass</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.getLoggerClass" title="Permalink to this definition">¶</a></dt>
<dd>Return either the standard <tt class="xref docutils literal">Logger</tt> class, or the last class passed to
<a title="logging.setLoggerClass" class="reference internal" href="#logging.setLoggerClass"><tt class="xref docutils literal">setLoggerClass()</tt></a>. This function may be called from within a new class
definition, to ensure that installing a customised <tt class="xref docutils literal">Logger</tt> class will
not undo customisations already applied by other code. For example:
<div class="highlight-python"><pre>class MyLogger(logging.getLoggerClass()):
 # ... override behaviour here</pre>
</div>
</dd></dl>

<dl class="function">
<dt id="logging.debug">
<tt class="descclassname">logging.</tt><tt class="descname">debug</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.debug" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">DEBUG</tt> on the root logger. The msg is the
message format string, and the args are the arguments which are merged into
msg using the string formatting operator. (Note that this means that you can
use keywords in the format string, together with a single dictionary argument.)
There are two keyword arguments in kwargs which are inspected: exc_info
which, if it does not evaluate as false, causes exception information to be
added to the logging message. If an exception tuple (in the format returned by
<a title="sys.exc_info" class="reference external" href="sys.html#sys.exc_info"><tt class="xref docutils literal">sys.exc_info()</tt></a>) is provided, it is used; otherwise, <a title="sys.exc_info" class="reference external" href="sys.html#sys.exc_info"><tt class="xref docutils literal">sys.exc_info()</tt></a>
is called to get the exception information.
The other optional keyword argument is extra which can be used to pass a
dictionary which is used to populate the __dict__ of the LogRecord created for
the logging event with user-defined attributes. These custom attributes can then
be used as you like. For example, they could be incorporated into logged
messages. For example:
<div class="highlight-python"><div class="highlight"><pre>FORMAT = &quot;%(asctime)-15s %(clientip)s %(user)-8s %(message)s&quot;
logging.basicConfig(format=FORMAT)
d = {&#39;clientip&#39;: &#39;192.168.0.1&#39;, &#39;user&#39;: &#39;fbloggs&#39;}
logging.warning(&quot;Protocol problem: %s&quot;, &quot;connection reset&quot;, extra=d)
</pre></div>
</div>
would print something like
<div class="highlight-python"><pre>2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset</pre>
</div>
The keys in the dictionary passed in extra should not clash with the keys used
by the logging system. (See the <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> documentation for more
information on which keys are used by the logging system.)
If you choose to use these attributes in logged messages, you need to exercise
some care. In the above example, for instance, the <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> has been
set up with a format string which expects &#8216;clientip&#8217; and &#8216;user&#8217; in the attribute
dictionary of the LogRecord. If these are missing, the message will not be
logged because a string formatting exception will occur. So in this case, you
always need to pass the extra dictionary with these keys.
While this might be annoying, this feature is intended for use in specialized
circumstances, such as multi-threaded servers where the same code executes in
many contexts, and interesting conditions which arise are dependent on this
context (such as remote client IP address and authenticated user name, in the
above example). In such circumstances, it is likely that specialized
<a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a>s would be used with particular <tt class="xref docutils literal">Handler</tt>s.

Changed in version 2.5: extra was added.
</dd></dl>

<dl class="function">
<dt id="logging.info">
<tt class="descclassname">logging.</tt><tt class="descname">info</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.info" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">INFO</tt> on the root logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="function">
<dt id="logging.warning">
<tt class="descclassname">logging.</tt><tt class="descname">warning</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.warning" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">WARNING</tt> on the root logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="function">
<dt id="logging.error">
<tt class="descclassname">logging.</tt><tt class="descname">error</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.error" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">ERROR</tt> on the root logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="function">
<dt id="logging.critical">
<tt class="descclassname">logging.</tt><tt class="descname">critical</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.critical" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">CRITICAL</tt> on the root logger. The arguments
are interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="function">
<dt id="logging.exception">
<tt class="descclassname">logging.</tt><tt class="descname">exception</tt><big>(</big>msg[, *args]<big>)</big><a class="headerlink" href="#logging.exception" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">ERROR</tt> on the root logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>. Exception info is added to the logging
message. This function should only be called from an exception handler.</dd></dl>

<dl class="function">
<dt id="logging.log">
<tt class="descclassname">logging.</tt><tt class="descname">log</tt><big>(</big>level, msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.log" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level level on the root logger. The other arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="function">
<dt id="logging.disable">
<tt class="descclassname">logging.</tt><tt class="descname">disable</tt><big>(</big>lvl<big>)</big><a class="headerlink" href="#logging.disable" title="Permalink to this definition">¶</a></dt>
<dd>Provides an overriding level lvl for all loggers which takes precedence over
the logger&#8217;s own level. When the need arises to temporarily throttle logging
output down across the whole application, this function can be useful. Its
effect is to disable all logging calls of severity lvl and below, so that
if you call it with a value of INFO, then all INFO and DEBUG events would be
discarded, whereas those of severity WARNING and above would be processed
according to the logger&#8217;s effective level.</dd></dl>

<dl class="function">
<dt id="logging.addLevelName">
<tt class="descclassname">logging.</tt><tt class="descname">addLevelName</tt><big>(</big>lvl, levelName<big>)</big><a class="headerlink" href="#logging.addLevelName" title="Permalink to this definition">¶</a></dt>
<dd>Associates level lvl with text levelName in an internal dictionary, which is
used to map numeric levels to a textual representation, for example when a
<a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> formats a message. This function can also be used to define
your own levels. The only constraints are that all levels used must be
registered using this function, levels should be positive integers and they
should increase in increasing order of severity.</dd></dl>

<dl class="function">
<dt id="logging.getLevelName">
<tt class="descclassname">logging.</tt><tt class="descname">getLevelName</tt><big>(</big>lvl<big>)</big><a class="headerlink" href="#logging.getLevelName" title="Permalink to this definition">¶</a></dt>
<dd>Returns the textual representation of logging level lvl. If the level is one
of the predefined levels <tt class="xref docutils literal">CRITICAL</tt>, <tt class="xref docutils literal">ERROR</tt>, <tt class="xref docutils literal">WARNING</tt>,
<tt class="xref docutils literal">INFO</tt> or <tt class="xref docutils literal">DEBUG</tt> then you get the corresponding string. If you
have associated levels with names using <a title="logging.addLevelName" class="reference internal" href="#logging.addLevelName"><tt class="xref docutils literal">addLevelName()</tt></a> then the name you
have associated with lvl is returned. If a numeric value corresponding to one
of the defined levels is passed in, the corresponding string representation is
returned. Otherwise, the string &#8220;Level %s&#8221; % lvl is returned.</dd></dl>

<dl class="function">
<dt id="logging.makeLogRecord">
<tt class="descclassname">logging.</tt><tt class="descname">makeLogRecord</tt><big>(</big>attrdict<big>)</big><a class="headerlink" href="#logging.makeLogRecord" title="Permalink to this definition">¶</a></dt>
<dd>Creates and returns a new <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instance whose attributes are
defined by attrdict. This function is useful for taking a pickled
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> attribute dictionary, sent over a socket, and reconstituting
it as a <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instance at the receiving end.</dd></dl>

<dl class="function">
<dt id="logging.basicConfig">
<tt class="descclassname">logging.</tt><tt class="descname">basicConfig</tt><big>(</big>[**kwargs]<big>)</big><a class="headerlink" href="#logging.basicConfig" title="Permalink to this definition">¶</a></dt>
<dd>Does basic configuration for the logging system by creating a
<a title="logging.StreamHandler" class="reference internal" href="#logging.StreamHandler"><tt class="xref docutils literal">StreamHandler</tt></a> with a default <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> and adding it to the
root logger. The functions <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>, <a title="logging.info" class="reference internal" href="#logging.info"><tt class="xref docutils literal">info()</tt></a>, <a title="logging.warning" class="reference internal" href="#logging.warning"><tt class="xref docutils literal">warning()</tt></a>,
<a title="logging.error" class="reference internal" href="#logging.error"><tt class="xref docutils literal">error()</tt></a> and <a title="logging.critical" class="reference internal" href="#logging.critical"><tt class="xref docutils literal">critical()</tt></a> will call <a title="logging.basicConfig" class="reference internal" href="#logging.basicConfig"><tt class="xref docutils literal">basicConfig()</tt></a> automatically
if no handlers are defined for the root logger.
This function does nothing if the root logger already has handlers
configured for it.

Changed in version 2.4: Formerly, <a title="logging.basicConfig" class="reference internal" href="#logging.basicConfig"><tt class="xref docutils literal">basicConfig()</tt></a> did not take any keyword arguments.
The following keyword arguments are supported.
<table border="1" class="docutils">
<colgroup>
<col width="24%" />
<col width="76%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Format</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">filename</tt></td>
<td>Specifies that a FileHandler be created,
using the specified filename, rather than a
StreamHandler.</td>
</tr>
<tr><td><tt class="docutils literal">filemode</tt></td>
<td>Specifies the mode to open the file, if
filename is specified (if filemode is
unspecified, it defaults to &#8216;a&#8217;).</td>
</tr>
<tr><td><tt class="docutils literal">format</tt></td>
<td>Use the specified format string for the
handler.</td>
</tr>
<tr><td><tt class="docutils literal">datefmt</tt></td>
<td>Use the specified date/time format.</td>
</tr>
<tr><td><tt class="docutils literal">level</tt></td>
<td>Set the root logger level to the specified
level.</td>
</tr>
<tr><td><tt class="docutils literal">stream</tt></td>
<td>Use the specified stream to initialize the
StreamHandler. Note that this argument is
incompatible with &#8216;filename&#8217; - if both are
present, &#8216;stream&#8217; is ignored.</td>
</tr>
</tbody>
</table>
</dd></dl>

<dl class="function">
<dt id="logging.shutdown">
<tt class="descclassname">logging.</tt><tt class="descname">shutdown</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.shutdown" title="Permalink to this definition">¶</a></dt>
<dd>Informs the logging system to perform an orderly shutdown by flushing and
closing all handlers. This should be called at application exit and no
further use of the logging system should be made after this call.</dd></dl>

<dl class="function">
<dt id="logging.setLoggerClass">
<tt class="descclassname">logging.</tt><tt class="descname">setLoggerClass</tt><big>(</big>klass<big>)</big><a class="headerlink" href="#logging.setLoggerClass" title="Permalink to this definition">¶</a></dt>
<dd>Tells the logging system to use the class klass when instantiating a logger.
The class should define <a title="object.__init__" class="reference external" href="../reference/datamodel.html#object.__init__"><tt class="xref docutils literal">__init__()</tt></a> such that only a name argument is
required, and the <a title="object.__init__" class="reference external" href="../reference/datamodel.html#object.__init__"><tt class="xref docutils literal">__init__()</tt></a> should call <tt class="xref docutils literal">Logger.__init__()</tt>. This
function is typically called before any loggers are instantiated by applications
which need to use custom logger behavior.</dd></dl>

<div class="admonition-see-also admonition seealso">
See also
<dl class="last docutils">
<dt><a class="reference external" href="http://www.python.org/dev/peps/pep-0282">PEP 282</a> - A Logging System</dt>
<dd>The proposal which described this feature for inclusion in the Python standard
library.</dd>
<dt><a class="reference external" href="http://www.red-dove.com/python_logging.html">Original Python logging package</a></dt>
<dd>This is the original source for the <tt class="xref docutils literal">logging</tt> package. The version of the
package available from this site is suitable for use with Python 1.5.2, 2.1.x
and 2.2.x, which do not include the <tt class="xref docutils literal">logging</tt> package in the standard
library.</dd>
</dl>
</div>
</div>
<div class="section" id="logger-objects">
<h2>15.6.5. Logger Objects<a class="headerlink" href="#logger-objects" title="Permalink to this headline">¶</a></h2>
Loggers have the following attributes and methods. Note that Loggers are never
instantiated directly, but always through the module-level function
<tt class="docutils literal">logging.getLogger(name)</tt>.
<dl class="attribute">
<dt id="logging.Logger.propagate">
<tt class="descclassname">Logger.</tt><tt class="descname">propagate</tt><a class="headerlink" href="#logging.Logger.propagate" title="Permalink to this definition">¶</a></dt>
<dd>If this evaluates to false, logging messages are not passed by this logger or by
its child loggers to the handlers of higher level (ancestor) loggers. The
constructor sets this attribute to 1.</dd></dl>

<dl class="method">
<dt id="logging.Logger.setLevel">
<tt class="descclassname">Logger.</tt><tt class="descname">setLevel</tt><big>(</big>lvl<big>)</big><a class="headerlink" href="#logging.Logger.setLevel" title="Permalink to this definition">¶</a></dt>
<dd>Sets the threshold for this logger to lvl. Logging messages which are less
severe than lvl will be ignored. When a logger is created, the level is set to
<tt class="xref docutils literal">NOTSET</tt> (which causes all messages to be processed when the logger is
the root logger, or delegation to the parent when the logger is a non-root
logger). Note that the root logger is created with level <tt class="xref docutils literal">WARNING</tt>.
The term &#8220;delegation to the parent&#8221; means that if a logger has a level of
NOTSET, its chain of ancestor loggers is traversed until either an ancestor with
a level other than NOTSET is found, or the root is reached.
If an ancestor is found with a level other than NOTSET, then that ancestor&#8217;s
level is treated as the effective level of the logger where the ancestor search
began, and is used to determine how a logging event is handled.
If the root is reached, and it has a level of NOTSET, then all messages will be
processed. Otherwise, the root&#8217;s level will be used as the effective level.
</dd></dl>

<dl class="method">
<dt id="logging.Logger.isEnabledFor">
<tt class="descclassname">Logger.</tt><tt class="descname">isEnabledFor</tt><big>(</big>lvl<big>)</big><a class="headerlink" href="#logging.Logger.isEnabledFor" title="Permalink to this definition">¶</a></dt>
<dd>Indicates if a message of severity lvl would be processed by this logger.
This method checks first the module-level level set by
<tt class="docutils literal">logging.disable(lvl)</tt> and then the logger&#8217;s effective level as determined
by <a title="logging.Logger.getEffectiveLevel" class="reference internal" href="#logging.Logger.getEffectiveLevel"><tt class="xref docutils literal">getEffectiveLevel()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Logger.getEffectiveLevel">
<tt class="descclassname">Logger.</tt><tt class="descname">getEffectiveLevel</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.Logger.getEffectiveLevel" title="Permalink to this definition">¶</a></dt>
<dd>Indicates the effective level for this logger. If a value other than
<tt class="xref docutils literal">NOTSET</tt> has been set using <a title="logging.Logger.setLevel" class="reference internal" href="#logging.Logger.setLevel"><tt class="xref docutils literal">setLevel()</tt></a>, it is returned. Otherwise,
the hierarchy is traversed towards the root until a value other than
<tt class="xref docutils literal">NOTSET</tt> is found, and that value is returned.</dd></dl>

<dl class="method">
<dt id="logging.Logger.debug">
<tt class="descclassname">Logger.</tt><tt class="descname">debug</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.Logger.debug" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">DEBUG</tt> on this logger. The msg is the
message format string, and the args are the arguments which are merged into
msg using the string formatting operator. (Note that this means that you can
use keywords in the format string, together with a single dictionary argument.)
There are two keyword arguments in kwargs which are inspected: exc_info
which, if it does not evaluate as false, causes exception information to be
added to the logging message. If an exception tuple (in the format returned by
<a title="sys.exc_info" class="reference external" href="sys.html#sys.exc_info"><tt class="xref docutils literal">sys.exc_info()</tt></a>) is provided, it is used; otherwise, <a title="sys.exc_info" class="reference external" href="sys.html#sys.exc_info"><tt class="xref docutils literal">sys.exc_info()</tt></a>
is called to get the exception information.
The other optional keyword argument is extra which can be used to pass a
dictionary which is used to populate the __dict__ of the LogRecord created for
the logging event with user-defined attributes. These custom attributes can then
be used as you like. For example, they could be incorporated into logged
messages. For example:
<div class="highlight-python"><div class="highlight"><pre>FORMAT = &quot;%(asctime)-15s %(clientip)s %(user)-8s %(message)s&quot;
logging.basicConfig(format=FORMAT)
d = { &#39;clientip&#39; : &#39;192.168.0.1&#39;, &#39;user&#39; : &#39;fbloggs&#39; }
logger = logging.getLogger(&quot;tcpserver&quot;)
logger.warning(&quot;Protocol problem: %s&quot;, &quot;connection reset&quot;, extra=d)
</pre></div>
</div>
would print something like
<div class="highlight-python"><pre>2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset</pre>
</div>
The keys in the dictionary passed in extra should not clash with the keys used
by the logging system. (See the <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> documentation for more
information on which keys are used by the logging system.)
If you choose to use these attributes in logged messages, you need to exercise
some care. In the above example, for instance, the <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> has been
set up with a format string which expects &#8216;clientip&#8217; and &#8216;user&#8217; in the attribute
dictionary of the LogRecord. If these are missing, the message will not be
logged because a string formatting exception will occur. So in this case, you
always need to pass the extra dictionary with these keys.
While this might be annoying, this feature is intended for use in specialized
circumstances, such as multi-threaded servers where the same code executes in
many contexts, and interesting conditions which arise are dependent on this
context (such as remote client IP address and authenticated user name, in the
above example). In such circumstances, it is likely that specialized
<a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a>s would be used with particular <tt class="xref docutils literal">Handler</tt>s.

Changed in version 2.5: extra was added.
</dd></dl>

<dl class="method">
<dt id="logging.Logger.info">
<tt class="descclassname">Logger.</tt><tt class="descname">info</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.Logger.info" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">INFO</tt> on this logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Logger.warning">
<tt class="descclassname">Logger.</tt><tt class="descname">warning</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.Logger.warning" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">WARNING</tt> on this logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Logger.error">
<tt class="descclassname">Logger.</tt><tt class="descname">error</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.Logger.error" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">ERROR</tt> on this logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Logger.critical">
<tt class="descclassname">Logger.</tt><tt class="descname">critical</tt><big>(</big>msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.Logger.critical" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">CRITICAL</tt> on this logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Logger.log">
<tt class="descclassname">Logger.</tt><tt class="descname">log</tt><big>(</big>lvl, msg[, *args[, **kwargs]]<big>)</big><a class="headerlink" href="#logging.Logger.log" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with integer level lvl on this logger. The other arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Logger.exception">
<tt class="descclassname">Logger.</tt><tt class="descname">exception</tt><big>(</big>msg[, *args]<big>)</big><a class="headerlink" href="#logging.Logger.exception" title="Permalink to this definition">¶</a></dt>
<dd>Logs a message with level <tt class="xref docutils literal">ERROR</tt> on this logger. The arguments are
interpreted as for <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>. Exception info is added to the logging
message. This method should only be called from an exception handler.</dd></dl>

<dl class="method">
<dt id="logging.Logger.addFilter">
<tt class="descclassname">Logger.</tt><tt class="descname">addFilter</tt><big>(</big>filt<big>)</big><a class="headerlink" href="#logging.Logger.addFilter" title="Permalink to this definition">¶</a></dt>
<dd>Adds the specified filter filt to this logger.</dd></dl>

<dl class="method">
<dt id="logging.Logger.removeFilter">
<tt class="descclassname">Logger.</tt><tt class="descname">removeFilter</tt><big>(</big>filt<big>)</big><a class="headerlink" href="#logging.Logger.removeFilter" title="Permalink to this definition">¶</a></dt>
<dd>Removes the specified filter filt from this logger.</dd></dl>

<dl class="method">
<dt id="logging.Logger.filter">
<tt class="descclassname">Logger.</tt><tt class="descname">filter</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Logger.filter" title="Permalink to this definition">¶</a></dt>
<dd>Applies this logger&#8217;s filters to the record and returns a true value if the
record is to be processed.</dd></dl>

<dl class="method">
<dt id="logging.Logger.addHandler">
<tt class="descclassname">Logger.</tt><tt class="descname">addHandler</tt><big>(</big>hdlr<big>)</big><a class="headerlink" href="#logging.Logger.addHandler" title="Permalink to this definition">¶</a></dt>
<dd>Adds the specified handler hdlr to this logger.</dd></dl>

<dl class="method">
<dt id="logging.Logger.removeHandler">
<tt class="descclassname">Logger.</tt><tt class="descname">removeHandler</tt><big>(</big>hdlr<big>)</big><a class="headerlink" href="#logging.Logger.removeHandler" title="Permalink to this definition">¶</a></dt>
<dd>Removes the specified handler hdlr from this logger.</dd></dl>

<dl class="method">
<dt id="logging.Logger.findCaller">
<tt class="descclassname">Logger.</tt><tt class="descname">findCaller</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.Logger.findCaller" title="Permalink to this definition">¶</a></dt>
<dd>Finds the caller&#8217;s source filename and line number. Returns the filename, line
number and function name as a 3-element tuple.

Changed in version 2.4: The function name was added. In earlier versions, the filename and line number
were returned as a 2-element tuple..
</dd></dl>

<dl class="method">
<dt id="logging.Logger.handle">
<tt class="descclassname">Logger.</tt><tt class="descname">handle</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Logger.handle" title="Permalink to this definition">¶</a></dt>
<dd>Handles a record by passing it to all handlers associated with this logger and
its ancestors (until a false value of propagate is found). This method is used
for unpickled records received from a socket, as well as those created locally.
Logger-level filtering is applied using <a title="logging.Logger.filter" class="reference internal" href="#logging.Logger.filter"><tt class="xref docutils literal">filter()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Logger.makeRecord">
<tt class="descclassname">Logger.</tt><tt class="descname">makeRecord</tt><big>(</big>name, lvl, fn, lno, msg, args, exc_info[, func, extra]<big>)</big><a class="headerlink" href="#logging.Logger.makeRecord" title="Permalink to this definition">¶</a></dt>
<dd>This is a factory method which can be overridden in subclasses to create
specialized <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instances.

Changed in version 2.5: func and extra were added.
</dd></dl>

</div>
<div class="section" id="basic-example">
<h2>15.6.6. Basic example<a class="headerlink" href="#basic-example" title="Permalink to this headline">¶</a></h2>

Changed in version 2.4: formerly <a title="logging.basicConfig" class="reference internal" href="#logging.basicConfig"><tt class="xref docutils literal">basicConfig()</tt></a> did not take any keyword arguments.
The <tt class="xref docutils literal">logging</tt> package provides a lot of flexibility, and its configuration
can appear daunting. This section demonstrates that simple use of the logging
package is possible.
The simplest example shows logging to the console:
<div class="highlight-python"><div class="highlight"><pre>import logging

logging.debug(&#39;A debug message&#39;)
logging.info(&#39;Some information&#39;)
logging.warning(&#39;A shot across the bows&#39;)
</pre></div>
</div>
If you run the above script, you&#8217;ll see this:
<div class="highlight-python"><pre>WARNING:root:A shot across the bows</pre>
</div>
Because no particular logger was specified, the system used the root logger. The
debug and info messages didn&#8217;t appear because by default, the root logger is
configured to only handle messages with a severity of WARNING or above. The
message format is also a configuration default, as is the output destination of
the messages - <tt class="docutils literal">sys.stderr</tt>. The severity level, the message format and
destination can be easily changed, as shown in the example below:
<div class="highlight-python"><div class="highlight"><pre>import logging

logging.basicConfig(level=logging.DEBUG,
 format=&#39;%(asctime)s %(levelname)s %(message)s&#39;,
 filename=&#39;myapp.log&#39;,
 filemode=&#39;w&#39;)
logging.debug(&#39;A debug message&#39;)
logging.info(&#39;Some information&#39;)
logging.warning(&#39;A shot across the bows&#39;)
</pre></div>
</div>
The <a title="logging.basicConfig" class="reference internal" href="#logging.basicConfig"><tt class="xref docutils literal">basicConfig()</tt></a> method is used to change the configuration defaults,
which results in output (written to <tt class="docutils literal">myapp.log</tt>) which should look
something like the following:
<div class="highlight-python"><pre>2004-07-02 13:00:08,743 DEBUG A debug message
2004-07-02 13:00:08,743 INFO Some information
2004-07-02 13:00:08,743 WARNING A shot across the bows</pre>
</div>
This time, all messages with a severity of DEBUG or above were handled, and the
format of the messages was also changed, and output went to the specified file
rather than the console.
Formatting uses standard Python string formatting - see section
<a class="reference external" href="stdtypes.html#string-formatting">String Formatting Operations</a>. The format string takes the following common
specifiers. For a complete list of specifiers, consult the <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a>
documentation.
<table border="1" class="docutils">
<colgroup>
<col width="29%" />
<col width="71%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Format</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">%(name)s</tt></td>
<td>Name of the logger (logging channel).</td>
</tr>
<tr><td><tt class="docutils literal">%(levelname)s</tt></td>
<td>Text logging level for the message
(<tt class="docutils literal">'DEBUG'</tt>, <tt class="docutils literal">'INFO'</tt>, <tt class="docutils literal">'WARNING'</tt>,
<tt class="docutils literal">'ERROR'</tt>, <tt class="docutils literal">'CRITICAL'</tt>).</td>
</tr>
<tr><td><tt class="docutils literal">%(asctime)s</tt></td>
<td>Human-readable time when the
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> was created. By default
this is of the form &#8220;2003-07-08 16:49:45,896&#8221;
(the numbers after the comma are millisecond
portion of the time).</td>
</tr>
<tr><td><tt class="docutils literal">%(message)s</tt></td>
<td>The logged message.</td>
</tr>
</tbody>
</table>
To change the date/time format, you can pass an additional keyword parameter,
datefmt, as in the following:
<div class="highlight-python"><div class="highlight"><pre>import logging

logging.basicConfig(level=logging.DEBUG,
 format=&#39;%(asctime)s %(levelname)-8s %(message)s&#39;,
 datefmt=&#39;%a, %d %b %Y %H:%M:%S&#39;,
 filename=&#39;/temp/myapp.log&#39;,
 filemode=&#39;w&#39;)
logging.debug(&#39;A debug message&#39;)
logging.info(&#39;Some information&#39;)
logging.warning(&#39;A shot across the bows&#39;)
</pre></div>
</div>
which would result in output like
<div class="highlight-python"><pre>Fri, 02 Jul 2004 13:06:18 DEBUG A debug message
Fri, 02 Jul 2004 13:06:18 INFO Some information
Fri, 02 Jul 2004 13:06:18 WARNING A shot across the bows</pre>
</div>
The date format string follows the requirements of <tt class="xref docutils literal">strftime()</tt> - see the
documentation for the <a title="Time access and conversions." class="reference external" href="time.html#module-time"><tt class="xref docutils literal">time</tt></a> module.
If, instead of sending logging output to the console or a file, you&#8217;d rather use
a file-like object which you have created separately, you can pass it to
<a title="logging.basicConfig" class="reference internal" href="#logging.basicConfig"><tt class="xref docutils literal">basicConfig()</tt></a> using the stream keyword argument. Note that if both
stream and filename keyword arguments are passed, the stream argument is
ignored.
Of course, you can put variable information in your output. To do this, simply
have the message be a format string and pass in additional arguments containing
the variable information, as in the following example:
<div class="highlight-python"><div class="highlight"><pre>import logging

# set up logging to file - see previous section for more details
logging.basicConfig(level=logging.DEBUG,
 format=&#39;%(asctime)s %(name)-12s %(levelname)-8s %(message)s&#39;,
 datefmt=&#39;%m-%d %H:%M&#39;,
 filename=&#39;/temp/myapp.log&#39;,
 filemode=&#39;w&#39;)
# define a Handler which writes INFO messages or higher to the sys.stderr
console = logging.StreamHandler()
console.setLevel(logging.INFO)
# set a format which is simpler for console use
formatter = logging.Formatter(&#39;%(name)-12s: %(levelname)-8s %(message)s&#39;)
# tell the handler to use this format
console.setFormatter(formatter)
# add the handler to the root logger
logging.getLogger(&#39;&#39;).addHandler(console)

# Now, we can log to the root logger, or any other logger. First the root...
logging.info(&#39;Jackdaws love my big sphinx of quartz.&#39;)

# Now, define a couple of other loggers which might represent areas in your
# application:

logger1 = logging.getLogger(&#39;myapp.area1&#39;)
logger2 = logging.getLogger(&#39;myapp.area2&#39;)

logger1.debug(&#39;Quick zephyrs blow, vexing daft Jim.&#39;)
logger1.info(&#39;How quickly daft jumping zebras vex.&#39;)
logger2.warning(&#39;Jail zesty vixen who grabbed pay from quack.&#39;)
logger2.error(&#39;The five boxing wizards jump quickly.&#39;)
</pre></div>
</div>
When you run this, on the console you will see
<div class="highlight-python"><pre>root : INFO Jackdaws love my big sphinx of quartz.
myapp.area1 : INFO How quickly daft jumping zebras vex.
myapp.area2 : WARNING Jail zesty vixen who grabbed pay from quack.
myapp.area2 : ERROR The five boxing wizards jump quickly.</pre>
</div>
and in the file you will see something like
<div class="highlight-python"><pre>10-22 22:19 root INFO Jackdaws love my big sphinx of quartz.
10-22 22:19 myapp.area1 DEBUG Quick zephyrs blow, vexing daft Jim.
10-22 22:19 myapp.area1 INFO How quickly daft jumping zebras vex.
10-22 22:19 myapp.area2 WARNING Jail zesty vixen who grabbed pay from quack.
10-22 22:19 myapp.area2 ERROR The five boxing wizards jump quickly.</pre>
</div>
As you can see, the DEBUG message only shows up in the file. The other messages
are sent to both destinations.
This example uses console and file handlers, but you can use any number and
combination of handlers you choose.
</div>
<div class="section" id="exceptions-raised-during-logging">
<h2>15.6.8. Exceptions raised during logging<a class="headerlink" href="#exceptions-raised-during-logging" title="Permalink to this headline">¶</a></h2>
The logging package is designed to swallow exceptions which occur while logging
in production. This is so that errors which occur while handling logging events
- such as logging misconfiguration, network or other similar errors - do not
cause the application using logging to terminate prematurely.
<tt class="xref docutils literal">SystemExit</tt> and <tt class="xref docutils literal">KeyboardInterrupt</tt> exceptions are never
swallowed. Other exceptions which occur during the <tt class="xref docutils literal">emit()</tt> method of a
<tt class="xref docutils literal">Handler</tt> subclass are passed to its <tt class="xref docutils literal">handleError()</tt> method.
The default implementation of <tt class="xref docutils literal">handleError()</tt> in <tt class="xref docutils literal">Handler</tt> checks
to see if a module-level variable, <tt class="xref docutils literal">raiseExceptions</tt>, is set. If set, a
traceback is printed to <a title="sys.stderr" class="reference external" href="sys.html#sys.stderr"><tt class="xref docutils literal">sys.stderr</tt></a>. If not set, the exception is swallowed.
Note: The default value of <tt class="xref docutils literal">raiseExceptions</tt> is <tt class="xref docutils literal">True</tt>. This is because
during development, you typically want to be notified of any exceptions that
occur. It&#8217;s advised that you set <tt class="xref docutils literal">raiseExceptions</tt> to <tt class="xref docutils literal">False</tt> for production
usage.
</div>
<div class="section" id="adding-contextual-information-to-your-logging-output">
<h2>15.6.9. Adding contextual information to your logging output<a class="headerlink" href="#adding-contextual-information-to-your-logging-output" title="Permalink to this headline">¶</a></h2>
Sometimes you want logging output to contain contextual information in
addition to the parameters passed to the logging call. For example, in a
networked application, it may be desirable to log client-specific information
in the log (e.g. remote client&#8217;s username, or IP address). Although you could
use the extra parameter to achieve this, it&#8217;s not always convenient to pass
the information in this way. While it might be tempting to create
<tt class="xref docutils literal">Logger</tt> instances on a per-connection basis, this is not a good idea
because these instances are not garbage collected. While this is not a problem
in practice, when the number of <tt class="xref docutils literal">Logger</tt> instances is dependent on the
level of granularity you want to use in logging an application, it could
be hard to manage if the number of <tt class="xref docutils literal">Logger</tt> instances becomes
effectively unbounded.
An easy way in which you can pass contextual information to be output along
with logging event information is to use the <a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a> class.
This class is designed to look like a <tt class="xref docutils literal">Logger</tt>, so that you can call
<a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>, <a title="logging.info" class="reference internal" href="#logging.info"><tt class="xref docutils literal">info()</tt></a>, <a title="logging.warning" class="reference internal" href="#logging.warning"><tt class="xref docutils literal">warning()</tt></a>, <a title="logging.error" class="reference internal" href="#logging.error"><tt class="xref docutils literal">error()</tt></a>,
<a title="logging.exception" class="reference internal" href="#logging.exception"><tt class="xref docutils literal">exception()</tt></a>, <a title="logging.critical" class="reference internal" href="#logging.critical"><tt class="xref docutils literal">critical()</tt></a> and <a title="logging.log" class="reference internal" href="#logging.log"><tt class="xref docutils literal">log()</tt></a>. These methods have the
same signatures as their counterparts in <tt class="xref docutils literal">Logger</tt>, so you can use the
two types of instances interchangeably.
When you create an instance of <a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a>, you pass it a
<tt class="xref docutils literal">Logger</tt> instance and a dict-like object which contains your contextual
information. When you call one of the logging methods on an instance of
<a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a>, it delegates the call to the underlying instance of
<tt class="xref docutils literal">Logger</tt> passed to its constructor, and arranges to pass the contextual
information in the delegated call. Here&#8217;s a snippet from the code of
<a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a>:
<div class="highlight-python"><div class="highlight"><pre>def debug(self, msg, *args, **kwargs):
 &quot;&quot;&quot;
 Delegate a debug call to the underlying logger, after adding
 contextual information from this adapter instance.
 &quot;&quot;&quot;
 msg, kwargs = self.process(msg, kwargs)
 self.logger.debug(msg, *args, **kwargs)
</pre></div>
</div>
The <tt class="xref docutils literal">process()</tt> method of <a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a> is where the contextual
information is added to the logging output. It&#8217;s passed the message and
keyword arguments of the logging call, and it passes back (potentially)
modified versions of these to use in the call to the underlying logger. The
default implementation of this method leaves the message alone, but inserts
an &#8220;extra&#8221; key in the keyword argument whose value is the dict-like object
passed to the constructor. Of course, if you had passed an &#8220;extra&#8221; keyword
argument in the call to the adapter, it will be silently overwritten.
The advantage of using &#8220;extra&#8221; is that the values in the dict-like object are
merged into the <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instance&#8217;s __dict__, allowing you to use
customized strings with your <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> instances which know about
the keys of the dict-like object. If you need a different method, e.g. if you
want to prepend or append the contextual information to the message string,
you just need to subclass <a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a> and override <tt class="xref docutils literal">process()</tt>
to do what you need. Here&#8217;s an example script which uses this class, which
also illustrates what dict-like behaviour is needed from an arbitrary
&#8220;dict-like&#8221; object for use in the constructor:
<div class="highlight-python"><div class="highlight"><pre>import logging

class ConnInfo:
 &quot;&quot;&quot;
 An example class which shows how an arbitrary class can be used as
 the &#39;extra&#39; context information repository passed to a LoggerAdapter.
 &quot;&quot;&quot;

def __getitem__(self, name):
 &quot;&quot;&quot;
 To allow this instance to look like a dict.
 &quot;&quot;&quot;
 from random import choice
 if name == &quot;ip&quot;:
 result = choice([&quot;127.0.0.1&quot;, &quot;192.168.0.1&quot;])
 elif name == &quot;user&quot;:
 result = choice([&quot;jim&quot;, &quot;fred&quot;, &quot;sheila&quot;])
 else:
 result = self.__dict__.get(name, &quot;?&quot;)
 return result

def __iter__(self):
 &quot;&quot;&quot;
 To allow iteration over keys, which will be merged into
 the LogRecord dict before formatting and output.
 &quot;&quot;&quot;
 keys = [&quot;ip&quot;, &quot;user&quot;]
 keys.extend(self.__dict__.keys())
 return keys.__iter__()

if __name__ == &quot;__main__&quot;:
 from random import choice
 levels = (logging.DEBUG, logging.INFO, logging.WARNING, logging.ERROR, logging.CRITICAL)
 a1 = logging.LoggerAdapter(logging.getLogger(&quot;a.b.c&quot;),
 { &quot;ip&quot; : &quot;123.231.231.123&quot;, &quot;user&quot; : &quot;sheila&quot; })
 logging.basicConfig(level=logging.DEBUG,
 format=&quot;%(asctime)-15s %(name)-5s %(levelname)-8s IP: %(ip)-15s User: %(user)-8s %(message)s&quot;)
 a1.debug(&quot;A debug message&quot;)
 a1.info(&quot;An info message with %s&quot;, &quot;some parameters&quot;)
 a2 = logging.LoggerAdapter(logging.getLogger(&quot;d.e.f&quot;), ConnInfo())
 for x in range(10):
 lvl = choice(levels)
 lvlname = logging.getLevelName(lvl)
 a2.log(lvl, &quot;A message at %s level with %d %s&quot;, lvlname, 2, &quot;parameters&quot;)
</pre></div>
</div>
When this script is run, the output should look something like this:
<div class="highlight-python"><pre>2008-01-18 14:49:54,023 a.b.c DEBUG IP: 123.231.231.123 User: sheila A debug message
2008-01-18 14:49:54,023 a.b.c INFO IP: 123.231.231.123 User: sheila An info message with some parameters
2008-01-18 14:49:54,023 d.e.f CRITICAL IP: 192.168.0.1 User: jim A message at CRITICAL level with 2 parameters
2008-01-18 14:49:54,033 d.e.f INFO IP: 192.168.0.1 User: jim A message at INFO level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: sheila A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f ERROR IP: 127.0.0.1 User: fred A message at ERROR level with 2 parameters
2008-01-18 14:49:54,033 d.e.f ERROR IP: 127.0.0.1 User: sheila A message at ERROR level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: sheila A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: jim A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f INFO IP: 192.168.0.1 User: fred A message at INFO level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 192.168.0.1 User: sheila A message at WARNING level with 2 parameters
2008-01-18 14:49:54,033 d.e.f WARNING IP: 127.0.0.1 User: jim A message at WARNING level with 2 parameters</pre>
</div>

New in version 2.6.
The <a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a> class was not present in previous versions.
</div>
<div class="section" id="logging-to-a-single-file-from-multiple-processes">
<h2>15.6.10. Logging to a single file from multiple processes<a class="headerlink" href="#logging-to-a-single-file-from-multiple-processes" title="Permalink to this headline">¶</a></h2>
Although logging is thread-safe, and logging to a single file from multiple
threads in a single process is supported, logging to a single file from
multiple processes is not supported, because there is no standard way to
serialize access to a single file across multiple processes in Python. If you
need to log to a single file from multiple processes, the best way of doing
this is to have all the processes log to a <a title="logging.SocketHandler" class="reference internal" href="#logging.SocketHandler"><tt class="xref docutils literal">SocketHandler</tt></a>, and have a
separate process which implements a socket server which reads from the socket
and logs to file. (If you prefer, you can dedicate one thread in one of the
existing processes to perform this function.) The following section documents
this approach in more detail and includes a working socket receiver which can
be used as a starting point for you to adapt in your own applications.
If you are using a recent version of Python which includes the
<a title="Process-based &quot;threading&quot; interface." class="reference external" href="multiprocessing.html#module-multiprocessing"><tt class="xref docutils literal">multiprocessing</tt></a> module, you can write your own handler which uses the
<tt class="xref docutils literal">Lock</tt> class from this module to serialize access to the file from
your processes. The existing <a title="logging.FileHandler" class="reference internal" href="#logging.FileHandler"><tt class="xref docutils literal">FileHandler</tt></a> and subclasses do not make
use of <a title="Process-based &quot;threading&quot; interface." class="reference external" href="multiprocessing.html#module-multiprocessing"><tt class="xref docutils literal">multiprocessing</tt></a> at present, though they may do so in the future.
Note that at present, the <a title="Process-based &quot;threading&quot; interface." class="reference external" href="multiprocessing.html#module-multiprocessing"><tt class="xref docutils literal">multiprocessing</tt></a> module does not provide
working lock functionality on all platforms (see
<a class="reference external" href="http://bugs.python.org/issue3770">http://bugs.python.org/issue3770</a>).
</div>
<div class="section" id="sending-and-receiving-logging-events-across-a-network">
<h2>15.6.11. Sending and receiving logging events across a network<a class="headerlink" href="#sending-and-receiving-logging-events-across-a-network" title="Permalink to this headline">¶</a></h2>
Let&#8217;s say you want to send logging events across a network, and handle them at
the receiving end. A simple way of doing this is attaching a
<a title="logging.SocketHandler" class="reference internal" href="#logging.SocketHandler"><tt class="xref docutils literal">SocketHandler</tt></a> instance to the root logger at the sending end:
<div class="highlight-python"><div class="highlight"><pre>import logging, logging.handlers

rootLogger = logging.getLogger(&#39;&#39;)
rootLogger.setLevel(logging.DEBUG)
socketHandler = logging.handlers.SocketHandler(&#39;localhost&#39;,
 logging.handlers.DEFAULT_TCP_LOGGING_PORT)
# don&#39;t bother with a formatter, since a socket handler sends the event as
# an unformatted pickle
rootLogger.addHandler(socketHandler)

# Now, define a couple of other loggers which might represent areas in your
# application:

logger1 = logging.getLogger(&#39;myapp.area1&#39;)
logger2 = logging.getLogger(&#39;myapp.area2&#39;)

class LogRecordStreamHandler(SocketServer.StreamRequestHandler):
 &quot;&quot;&quot;Handler for a streaming logging request.

This basically logs the record using whatever logging policy is
 configured locally.
 &quot;&quot;&quot;

def handle(self):
 &quot;&quot;&quot;
 Handle multiple requests - each expected to be a 4-byte length,
 followed by the LogRecord in pickle format. Logs the record
 according to whatever policy is configured locally.
 &quot;&quot;&quot;
 while 1:
 chunk = self.connection.recv(4)
 if len(chunk) &lt; 4:
 break
 slen = struct.unpack(&quot;&gt;L&quot;, chunk)[0]
 chunk = self.connection.recv(slen)
 while len(chunk) &lt; slen:
 chunk = chunk + self.connection.recv(slen - len(chunk))
 obj = self.unPickle(chunk)
 record = logging.makeLogRecord(obj)
 self.handleLogRecord(record)

def unPickle(self, data):
 return cPickle.loads(data)

def handleLogRecord(self, record):
 # if a name is specified, we use the named logger rather than the one
 # implied by the record.
 if self.server.logname is not None:
 name = self.server.logname
 else:
 name = record.name
 logger = logging.getLogger(name)
 # N.B. EVERY record gets logged. This is because Logger.handle
 # is normally called AFTER logger-level filtering. If you want
 # to do filtering, do it at the client end to save wasting
 # cycles and network bandwidth!
 logger.handle(record)

class LogRecordSocketReceiver(SocketServer.ThreadingTCPServer):
 &quot;&quot;&quot;simple TCP socket-based logging receiver suitable for testing.
 &quot;&quot;&quot;

allow_reuse_address = 1

def __init__(self, host=&#39;localhost&#39;,
 port=logging.handlers.DEFAULT_TCP_LOGGING_PORT,
 handler=LogRecordStreamHandler):
 SocketServer.ThreadingTCPServer.__init__(self, (host, port), handler)
 self.abort = 0
 self.timeout = 1
 self.logname = None

def serve_until_stopped(self):
 import select
 abort = 0
 while not abort:
 rd, wr, ex = select.select([self.socket.fileno()],
 [], [],
 self.timeout)
 if rd:
 self.handle_request()
 abort = self.abort

def main():
 logging.basicConfig(
 format=&quot;%(relativeCreated)5d %(name)-15s %(levelname)-8s %(message)s&quot;)
 tcpserver = LogRecordSocketReceiver()
 print &quot;About to start TCP server...&quot;
 tcpserver.serve_until_stopped()

if __name__ == &quot;__main__&quot;:
 main()
</pre></div>
</div>
First run the server, and then the client. On the client side, nothing is
printed on the console; on the server side, you should see something like:
<div class="highlight-python"><pre>About to start TCP server...
 59 root INFO Jackdaws love my big sphinx of quartz.
 59 myapp.area1 DEBUG Quick zephyrs blow, vexing daft Jim.
 69 myapp.area1 INFO How quickly daft jumping zebras vex.
 69 myapp.area2 WARNING Jail zesty vixen who grabbed pay from quack.
 69 myapp.area2 ERROR The five boxing wizards jump quickly.</pre>
</div>
Note that there are some security issues with pickle in some scenarios. If
these affect you, you can use an alternative serialization scheme by overriding
the <tt class="xref docutils literal">makePickle()</tt> method and implementing your alternative there, as
well as adapting the above script to use your alternative serialization.
</div>
<div class="section" id="using-arbitrary-objects-as-messages">
<h2>15.6.12. Using arbitrary objects as messages<a class="headerlink" href="#using-arbitrary-objects-as-messages" title="Permalink to this headline">¶</a></h2>
In the preceding sections and examples, it has been assumed that the message
passed when logging the event is a string. However, this is not the only
possibility. You can pass an arbitrary object as a message, and its
<a title="object.__str__" class="reference external" href="../reference/datamodel.html#object.__str__"><tt class="xref docutils literal">__str__()</tt></a> method will be called when the logging system needs to convert
it to a string representation. In fact, if you want to, you can avoid
computing a string representation altogether - for example, the
<a title="logging.SocketHandler" class="reference internal" href="#logging.SocketHandler"><tt class="xref docutils literal">SocketHandler</tt></a> emits an event by pickling it and sending it over the
wire.
</div>
<div class="section" id="optimization">
<h2>15.6.13. Optimization<a class="headerlink" href="#optimization" title="Permalink to this headline">¶</a></h2>
Formatting of message arguments is deferred until it cannot be avoided.
However, computing the arguments passed to the logging method can also be
expensive, and you may want to avoid doing it if the logger will just throw
away your event. To decide what to do, you can call the <tt class="xref docutils literal">isEnabledFor()</tt>
method which takes a level argument and returns true if the event would be
created by the Logger for that level of call. You can write code like this:
<div class="highlight-python"><div class="highlight"><pre>if logger.isEnabledFor(logging.DEBUG):
 logger.debug(&quot;Message with %s, %s&quot;, expensive_func1(),
 expensive_func2())
</pre></div>
</div>
so that if the logger&#8217;s threshold is set above <tt class="docutils literal">DEBUG</tt>, the calls to
<tt class="xref docutils literal">expensive_func1()</tt> and <tt class="xref docutils literal">expensive_func2()</tt> are never made.
There are other optimizations which can be made for specific applications which
need more precise control over what logging information is collected. Here&#8217;s a
list of things you can do to avoid processing during logging which you don&#8217;t
need:
<table border="1" class="docutils">
<colgroup>
<col width="54%" />
<col width="46%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">What you don&#8217;t want to collect</th>
<th class="head">How to avoid collecting it</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Information about where calls were made from.</td>
<td>Set <tt class="docutils literal">logging._srcfile</tt> to <tt class="xref docutils literal">None</tt>.</td>
</tr>
<tr><td>Threading information.</td>
<td>Set <tt class="docutils literal">logging.logThreads</tt> to <tt class="docutils literal">0</tt>.</td>
</tr>
<tr><td>Process information.</td>
<td>Set <tt class="docutils literal">logging.logProcesses</tt> to <tt class="docutils literal">0</tt>.</td>
</tr>
</tbody>
</table>
Also note that the core logging module only includes the basic handlers. If
you don&#8217;t import <tt class="xref docutils literal">logging.handlers</tt> and <tt class="xref docutils literal">logging.config</tt>, they won&#8217;t
take up any memory.
</div>
<div class="section" id="handler-objects">
<h2>15.6.14. Handler Objects<a class="headerlink" href="#handler-objects" title="Permalink to this headline">¶</a></h2>
Handlers have the following attributes and methods. Note that <tt class="xref docutils literal">Handler</tt>
is never instantiated directly; this class acts as a base for more useful
subclasses. However, the <a title="object.__init__" class="reference external" href="../reference/datamodel.html#object.__init__"><tt class="xref docutils literal">__init__()</tt></a> method in subclasses needs to call
<a title="logging.Handler.__init__" class="reference internal" href="#logging.Handler.__init__"><tt class="xref docutils literal">Handler.__init__()</tt></a>.
<dl class="method">
<dt id="logging.Handler.__init__">
<tt class="descclassname">Handler.</tt><tt class="descname">__init__</tt><big>(</big>level=NOTSET<big>)</big><a class="headerlink" href="#logging.Handler.__init__" title="Permalink to this definition">¶</a></dt>
<dd>Initializes the <tt class="xref docutils literal">Handler</tt> instance by setting its level, setting the list
of filters to the empty list and creating a lock (using <a title="logging.Handler.createLock" class="reference internal" href="#logging.Handler.createLock"><tt class="xref docutils literal">createLock()</tt></a>) for
serializing access to an I/O mechanism.</dd></dl>

<dl class="method">
<dt id="logging.Handler.createLock">
<tt class="descclassname">Handler.</tt><tt class="descname">createLock</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.Handler.createLock" title="Permalink to this definition">¶</a></dt>
<dd>Initializes a thread lock which can be used to serialize access to underlying
I/O functionality which may not be threadsafe.</dd></dl>

<dl class="method">
<dt id="logging.Handler.acquire">
<tt class="descclassname">Handler.</tt><tt class="descname">acquire</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.Handler.acquire" title="Permalink to this definition">¶</a></dt>
<dd>Acquires the thread lock created with <a title="logging.Handler.createLock" class="reference internal" href="#logging.Handler.createLock"><tt class="xref docutils literal">createLock()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Handler.release">
<tt class="descclassname">Handler.</tt><tt class="descname">release</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.Handler.release" title="Permalink to this definition">¶</a></dt>
<dd>Releases the thread lock acquired with <a title="logging.Handler.acquire" class="reference internal" href="#logging.Handler.acquire"><tt class="xref docutils literal">acquire()</tt></a>.</dd></dl>

<dl class="method">
<dt id="logging.Handler.setLevel">
<tt class="descclassname">Handler.</tt><tt class="descname">setLevel</tt><big>(</big>lvl<big>)</big><a class="headerlink" href="#logging.Handler.setLevel" title="Permalink to this definition">¶</a></dt>
<dd>Sets the threshold for this handler to lvl. Logging messages which are less
severe than lvl will be ignored. When a handler is created, the level is set
to <tt class="xref docutils literal">NOTSET</tt> (which causes all messages to be processed).</dd></dl>

<dl class="method">
<dt id="logging.Handler.setFormatter">
<tt class="descclassname">Handler.</tt><tt class="descname">setFormatter</tt><big>(</big>form<big>)</big><a class="headerlink" href="#logging.Handler.setFormatter" title="Permalink to this definition">¶</a></dt>
<dd>Sets the <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> for this handler to form.</dd></dl>

<dl class="method">
<dt id="logging.Handler.addFilter">
<tt class="descclassname">Handler.</tt><tt class="descname">addFilter</tt><big>(</big>filt<big>)</big><a class="headerlink" href="#logging.Handler.addFilter" title="Permalink to this definition">¶</a></dt>
<dd>Adds the specified filter filt to this handler.</dd></dl>

<dl class="method">
<dt id="logging.Handler.removeFilter">
<tt class="descclassname">Handler.</tt><tt class="descname">removeFilter</tt><big>(</big>filt<big>)</big><a class="headerlink" href="#logging.Handler.removeFilter" title="Permalink to this definition">¶</a></dt>
<dd>Removes the specified filter filt from this handler.</dd></dl>

<dl class="method">
<dt id="logging.Handler.filter">
<tt class="descclassname">Handler.</tt><tt class="descname">filter</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Handler.filter" title="Permalink to this definition">¶</a></dt>
<dd>Applies this handler&#8217;s filters to the record and returns a true value if the
record is to be processed.</dd></dl>

<dl class="method">
<dt id="logging.Handler.flush">
<tt class="descclassname">Handler.</tt><tt class="descname">flush</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.Handler.flush" title="Permalink to this definition">¶</a></dt>
<dd>Ensure all logging output has been flushed. This version does nothing and is
intended to be implemented by subclasses.</dd></dl>

<dl class="method">
<dt id="logging.Handler.close">
<tt class="descclassname">Handler.</tt><tt class="descname">close</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.Handler.close" title="Permalink to this definition">¶</a></dt>
<dd>Tidy up any resources used by the handler. This version does no output but
removes the handler from an internal list of handlers which is closed when
<a title="logging.shutdown" class="reference internal" href="#logging.shutdown"><tt class="xref docutils literal">shutdown()</tt></a> is called. Subclasses should ensure that this gets called
from overridden <a title="logging.Handler.close" class="reference internal" href="#logging.Handler.close"><tt class="xref docutils literal">close()</tt></a> methods.</dd></dl>

<dl class="method">
<dt id="logging.Handler.handle">
<tt class="descclassname">Handler.</tt><tt class="descname">handle</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Handler.handle" title="Permalink to this definition">¶</a></dt>
<dd>Conditionally emits the specified logging record, depending on filters which may
have been added to the handler. Wraps the actual emission of the record with
acquisition/release of the I/O thread lock.</dd></dl>

<dl class="method">
<dt id="logging.Handler.handleError">
<tt class="descclassname">Handler.</tt><tt class="descname">handleError</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Handler.handleError" title="Permalink to this definition">¶</a></dt>
<dd>This method should be called from handlers when an exception is encountered
during an <a title="logging.Handler.emit" class="reference internal" href="#logging.Handler.emit"><tt class="xref docutils literal">emit()</tt></a> call. By default it does nothing, which means that
exceptions get silently ignored. This is what is mostly wanted for a logging
system - most users will not care about errors in the logging system, they are
more interested in application errors. You could, however, replace this with a
custom handler if you wish. The specified record is the one which was being
processed when the exception occurred.</dd></dl>

<dl class="method">
<dt id="logging.Handler.format">
<tt class="descclassname">Handler.</tt><tt class="descname">format</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Handler.format" title="Permalink to this definition">¶</a></dt>
<dd>Do formatting for a record - if a formatter is set, use it. Otherwise, use the
default formatter for the module.</dd></dl>

<dl class="method">
<dt id="logging.Handler.emit">
<tt class="descclassname">Handler.</tt><tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Handler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Do whatever it takes to actually log the specified logging record. This version
is intended to be implemented by subclasses and so raises a
<a title="exceptions.NotImplementedError" class="reference external" href="exceptions.html#exceptions.NotImplementedError"><tt class="xref docutils literal">NotImplementedError</tt></a>.</dd></dl>

<div class="section" id="streamhandler">
<h3>15.6.14.1. StreamHandler<a class="headerlink" href="#streamhandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.StreamHandler" class="reference internal" href="#logging.StreamHandler"><tt class="xref docutils literal">StreamHandler</tt></a> class, located in the core <tt class="xref docutils literal">logging</tt> package,
sends logging output to streams such as sys.stdout, sys.stderr or any
file-like object (or, more precisely, any object which supports <tt class="xref docutils literal">write()</tt>
and <tt class="xref docutils literal">flush()</tt> methods).
<dl class="class">
<dt id="logging.StreamHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">StreamHandler</tt><big>(</big>[strm]<big>)</big><a class="headerlink" href="#logging.StreamHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.StreamHandler" class="reference internal" href="#logging.StreamHandler"><tt class="xref docutils literal">StreamHandler</tt></a> class. If strm is
specified, the instance will use it for logging output; otherwise, sys.stderr
will be used.
<dl class="method">
<dt id="logging.StreamHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.StreamHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>If a formatter is specified, it is used to format the record. The record
is then written to the stream with a trailing newline. If exception
information is present, it is formatted using
<a title="traceback.print_exception" class="reference external" href="traceback.html#traceback.print_exception"><tt class="xref docutils literal">traceback.print_exception()</tt></a> and appended to the stream.</dd></dl>

<dl class="method">
<dt id="logging.StreamHandler.flush">
<tt class="descname">flush</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.StreamHandler.flush" title="Permalink to this definition">¶</a></dt>
<dd>Flushes the stream by calling its <a title="logging.StreamHandler.flush" class="reference internal" href="#logging.StreamHandler.flush"><tt class="xref docutils literal">flush()</tt></a> method. Note that the
<tt class="xref docutils literal">close()</tt> method is inherited from <tt class="xref docutils literal">Handler</tt> and so does
no output, so an explicit <a title="logging.StreamHandler.flush" class="reference internal" href="#logging.StreamHandler.flush"><tt class="xref docutils literal">flush()</tt></a> call may be needed at times.</dd></dl>

</dd></dl>

</div>
<div class="section" id="filehandler">
<h3>15.6.14.2. FileHandler<a class="headerlink" href="#filehandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.FileHandler" class="reference internal" href="#logging.FileHandler"><tt class="xref docutils literal">FileHandler</tt></a> class, located in the core <tt class="xref docutils literal">logging</tt> package,
sends logging output to a disk file. It inherits the output functionality from
<a title="logging.StreamHandler" class="reference internal" href="#logging.StreamHandler"><tt class="xref docutils literal">StreamHandler</tt></a>.
<dl class="class">
<dt id="logging.FileHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">FileHandler</tt><big>(</big>filename[, mode[, encoding[, delay]]]<big>)</big><a class="headerlink" href="#logging.FileHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.FileHandler" class="reference internal" href="#logging.FileHandler"><tt class="xref docutils literal">FileHandler</tt></a> class. The specified file is
opened and used as the stream for logging. If mode is not specified,
<tt class="xref docutils literal">'a'</tt> is used. If encoding is not None, it is used to open the file
with that encoding. If delay is true, then file opening is deferred until the
first call to <a title="logging.FileHandler.emit" class="reference internal" href="#logging.FileHandler.emit"><tt class="xref docutils literal">emit()</tt></a>. By default, the file grows indefinitely.

Changed in version 2.6: delay was added.
<dl class="method">
<dt id="logging.FileHandler.close">
<tt class="descname">close</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.FileHandler.close" title="Permalink to this definition">¶</a></dt>
<dd>Closes the file.</dd></dl>

<dl class="method">
<dt id="logging.FileHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.FileHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Outputs the record to the file.</dd></dl>

</dd></dl>

See <a class="reference internal" href="#library-config">Configuring Logging for a Library</a> for more information on how to use
<tt class="xref docutils literal">NullHandler</tt>.
</div>
<div class="section" id="watchedfilehandler">
<h3>15.6.14.3. WatchedFileHandler<a class="headerlink" href="#watchedfilehandler" title="Permalink to this headline">¶</a></h3>

New in version 2.6.
The <a title="logging.WatchedFileHandler" class="reference internal" href="#logging.WatchedFileHandler"><tt class="xref docutils literal">WatchedFileHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt>
module, is a <a title="logging.FileHandler" class="reference internal" href="#logging.FileHandler"><tt class="xref docutils literal">FileHandler</tt></a> which watches the file it is logging to. If
the file changes, it is closed and reopened using the file name.
A file change can happen because of usage of programs such as newsyslog and
logrotate which perform log file rotation. This handler, intended for use
under Unix/Linux, watches the file to see if it has changed since the last emit.
(A file is deemed to have changed if its device or inode have changed.) If the
file has changed, the old file stream is closed, and the file opened to get a
new stream.
This handler is not appropriate for use under Windows, because under Windows
open log files cannot be moved or renamed - logging opens the files with
exclusive locks - and so there is no need for such a handler. Furthermore,
ST_INO is not supported under Windows; <tt class="xref docutils literal">stat()</tt> always returns zero for
this value.
<dl class="class">
<dt id="logging.WatchedFileHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">WatchedFileHandler</tt><big>(</big>filename[, mode[, encoding[, delay]]]<big>)</big><a class="headerlink" href="#logging.WatchedFileHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.WatchedFileHandler" class="reference internal" href="#logging.WatchedFileHandler"><tt class="xref docutils literal">WatchedFileHandler</tt></a> class. The specified
file is opened and used as the stream for logging. If mode is not specified,
<tt class="xref docutils literal">'a'</tt> is used. If encoding is not None, it is used to open the file
with that encoding. If delay is true, then file opening is deferred until the
first call to <a title="logging.WatchedFileHandler.emit" class="reference internal" href="#logging.WatchedFileHandler.emit"><tt class="xref docutils literal">emit()</tt></a>. By default, the file grows indefinitely.

Changed in version 2.6: delay was added.
<dl class="method">
<dt id="logging.WatchedFileHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.WatchedFileHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Outputs the record to the file, but first checks to see if the file has
changed. If it has, the existing stream is flushed and closed and the
file opened again, before outputting the record to the file.</dd></dl>

</dd></dl>

</div>
<div class="section" id="rotatingfilehandler">
<h3>15.6.14.4. RotatingFileHandler<a class="headerlink" href="#rotatingfilehandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.RotatingFileHandler" class="reference internal" href="#logging.RotatingFileHandler"><tt class="xref docutils literal">RotatingFileHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt>
module, supports rotation of disk log files.
<dl class="class">
<dt id="logging.RotatingFileHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">RotatingFileHandler</tt><big>(</big>filename[, mode[, maxBytes[, backupCount[, encoding[, delay]]]]]<big>)</big><a class="headerlink" href="#logging.RotatingFileHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.RotatingFileHandler" class="reference internal" href="#logging.RotatingFileHandler"><tt class="xref docutils literal">RotatingFileHandler</tt></a> class. The specified
file is opened and used as the stream for logging. If mode is not specified,
<tt class="docutils literal">'a'</tt> is used. If encoding is not None, it is used to open the file
with that encoding. If delay is true, then file opening is deferred until the
first call to <a title="logging.RotatingFileHandler.emit" class="reference internal" href="#logging.RotatingFileHandler.emit"><tt class="xref docutils literal">emit()</tt></a>. By default, the file grows indefinitely.
You can use the maxBytes and backupCount values to allow the file to
rollover at a predetermined size. When the size is about to be exceeded,
the file is closed and a new file is silently opened for output. Rollover occurs
whenever the current log file is nearly maxBytes in length; if maxBytes is
zero, rollover never occurs. If backupCount is non-zero, the system will save
old log files by appending the extensions &#8220;.1&#8221;, &#8220;.2&#8221; etc., to the filename. For
example, with a backupCount of 5 and a base file name of <tt class="docutils literal">app.log</tt>, you
would get <tt class="docutils literal">app.log</tt>, <tt class="docutils literal">app.log.1</tt>, <tt class="docutils literal">app.log.2</tt>, up to
<tt class="docutils literal">app.log.5</tt>. The file being written to is always <tt class="docutils literal">app.log</tt>. When
this file is filled, it is closed and renamed to <tt class="docutils literal">app.log.1</tt>, and if files
<tt class="docutils literal">app.log.1</tt>, <tt class="docutils literal">app.log.2</tt>, etc. exist, then they are renamed to
<tt class="docutils literal">app.log.2</tt>, <tt class="docutils literal">app.log.3</tt> etc. respectively.

Changed in version 2.6: delay was added.
<dl class="method">
<dt id="logging.RotatingFileHandler.doRollover">
<tt class="descname">doRollover</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.RotatingFileHandler.doRollover" title="Permalink to this definition">¶</a></dt>
<dd>Does a rollover, as described above.</dd></dl>

<dl class="method">
<dt id="logging.RotatingFileHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.RotatingFileHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Outputs the record to the file, catering for rollover as described
previously.</dd></dl>

</dd></dl>

</div>
<div class="section" id="timedrotatingfilehandler">
<h3>15.6.14.5. TimedRotatingFileHandler<a class="headerlink" href="#timedrotatingfilehandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.TimedRotatingFileHandler" class="reference internal" href="#logging.TimedRotatingFileHandler"><tt class="xref docutils literal">TimedRotatingFileHandler</tt></a> class, located in the
<tt class="xref docutils literal">logging.handlers</tt> module, supports rotation of disk log files at certain
timed intervals.
<dl class="class">
<dt id="logging.TimedRotatingFileHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">TimedRotatingFileHandler</tt><big>(</big>filename[, when[, interval[, backupCount[, encoding[, delay[, utc]]]]]]<big>)</big><a class="headerlink" href="#logging.TimedRotatingFileHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.TimedRotatingFileHandler" class="reference internal" href="#logging.TimedRotatingFileHandler"><tt class="xref docutils literal">TimedRotatingFileHandler</tt></a> class. The
specified file is opened and used as the stream for logging. On rotating it also
sets the filename suffix. Rotating happens based on the product of when and
interval.
You can use the when to specify the type of interval. The list of possible
values is below. Note that they are not case sensitive.
<table border="1" class="docutils">
<colgroup>
<col width="41%" />
<col width="59%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Value</th>
<th class="head">Type of interval</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">'S'</tt></td>
<td>Seconds</td>
</tr>
<tr><td><tt class="docutils literal">'M'</tt></td>
<td>Minutes</td>
</tr>
<tr><td><tt class="docutils literal">'H'</tt></td>
<td>Hours</td>
</tr>
<tr><td><tt class="docutils literal">'D'</tt></td>
<td>Days</td>
</tr>
<tr><td><tt class="docutils literal">'W'</tt></td>
<td>Week day (0=Monday)</td>
</tr>
<tr><td><tt class="docutils literal">'midnight'</tt></td>
<td>Roll over at midnight</td>
</tr>
</tbody>
</table>
The system will save old log files by appending extensions to the filename.
The extensions are date-and-time based, using the strftime format
<tt class="docutils literal">%Y-%m-%d_%H-%M-%S</tt> or a leading portion thereof, depending on the
rollover interval.
When computing the next rollover time for the first time (when the handler
is created), the last modification time of an existing log file, or else
the current time, is used to compute when the next rotation will occur.
If the utc argument is true, times in UTC will be used; otherwise
local time is used.
If backupCount is nonzero, at most backupCount files
will be kept, and if more would be created when rollover occurs, the oldest
one is deleted. The deletion logic uses the interval to determine which
files to delete, so changing the interval may leave old files lying around.
If delay is true, then file opening is deferred until the first call to
<a title="logging.TimedRotatingFileHandler.emit" class="reference internal" href="#logging.TimedRotatingFileHandler.emit"><tt class="xref docutils literal">emit()</tt></a>.

Changed in version 2.6: delay was added.
<dl class="method">
<dt id="logging.TimedRotatingFileHandler.doRollover">
<tt class="descname">doRollover</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.TimedRotatingFileHandler.doRollover" title="Permalink to this definition">¶</a></dt>
<dd>Does a rollover, as described above.</dd></dl>

<dl class="method">
<dt id="logging.TimedRotatingFileHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.TimedRotatingFileHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Outputs the record to the file, catering for rollover as described above.</dd></dl>

</dd></dl>

</div>
<div class="section" id="sockethandler">
<h3>15.6.14.6. SocketHandler<a class="headerlink" href="#sockethandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.SocketHandler" class="reference internal" href="#logging.SocketHandler"><tt class="xref docutils literal">SocketHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt> module,
sends logging output to a network socket. The base class uses a TCP socket.
<dl class="class">
<dt id="logging.SocketHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">SocketHandler</tt><big>(</big>host, port<big>)</big><a class="headerlink" href="#logging.SocketHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.SocketHandler" class="reference internal" href="#logging.SocketHandler"><tt class="xref docutils literal">SocketHandler</tt></a> class intended to
communicate with a remote machine whose address is given by host and port.
<dl class="method">
<dt id="logging.SocketHandler.close">
<tt class="descname">close</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.SocketHandler.close" title="Permalink to this definition">¶</a></dt>
<dd>Closes the socket.</dd></dl>

<dl class="method">
<dt id="logging.SocketHandler.emit">
<tt class="descname">emit</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.SocketHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Pickles the record&#8217;s attribute dictionary and writes it to the socket in
binary format. If there is an error with the socket, silently drops the
packet. If the connection was previously lost, re-establishes the
connection. To unpickle the record at the receiving end into a
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a>, use the <a title="logging.makeLogRecord" class="reference internal" href="#logging.makeLogRecord"><tt class="xref docutils literal">makeLogRecord()</tt></a> function.</dd></dl>

<dl class="method">
<dt id="logging.SocketHandler.handleError">
<tt class="descname">handleError</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.SocketHandler.handleError" title="Permalink to this definition">¶</a></dt>
<dd>Handles an error which has occurred during <a title="logging.SocketHandler.emit" class="reference internal" href="#logging.SocketHandler.emit"><tt class="xref docutils literal">emit()</tt></a>. The most likely
cause is a lost connection. Closes the socket so that we can retry on the
next event.</dd></dl>

<dl class="method">
<dt id="logging.SocketHandler.makeSocket">
<tt class="descname">makeSocket</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.SocketHandler.makeSocket" title="Permalink to this definition">¶</a></dt>
<dd>This is a factory method which allows subclasses to define the precise
type of socket they want. The default implementation creates a TCP socket
(<a title="socket.SOCK_STREAM" class="reference external" href="socket.html#socket.SOCK_STREAM"><tt class="xref docutils literal">socket.SOCK_STREAM</tt></a>).</dd></dl>

<dl class="method">
<dt id="logging.SocketHandler.makePickle">
<tt class="descname">makePickle</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.SocketHandler.makePickle" title="Permalink to this definition">¶</a></dt>
<dd>Pickles the record&#8217;s attribute dictionary in binary format with a length
prefix, and returns it ready for transmission across the socket.
Note that pickles aren&#8217;t completely secure. If you are concerned about
security, you may want to override this method to implement a more secure
mechanism. For example, you can sign pickles using HMAC and then verify
them on the receiving end, or alternatively you can disable unpickling of
global objects on the receiving end.
</dd></dl>

<dl class="method">
<dt id="logging.SocketHandler.send">
<tt class="descname">send</tt><big>(</big>packet<big>)</big><a class="headerlink" href="#logging.SocketHandler.send" title="Permalink to this definition">¶</a></dt>
<dd>Send a pickled string packet to the socket. This function allows for
partial sends which can happen when the network is busy.</dd></dl>

</dd></dl>

</div>
<div class="section" id="datagramhandler">
<h3>15.6.14.7. DatagramHandler<a class="headerlink" href="#datagramhandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.DatagramHandler" class="reference internal" href="#logging.DatagramHandler"><tt class="xref docutils literal">DatagramHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt>
module, inherits from <a title="logging.SocketHandler" class="reference internal" href="#logging.SocketHandler"><tt class="xref docutils literal">SocketHandler</tt></a> to support sending logging messages
over UDP sockets.
<dl class="class">
<dt id="logging.DatagramHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">DatagramHandler</tt><big>(</big>host, port<big>)</big><a class="headerlink" href="#logging.DatagramHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.DatagramHandler" class="reference internal" href="#logging.DatagramHandler"><tt class="xref docutils literal">DatagramHandler</tt></a> class intended to
communicate with a remote machine whose address is given by host and port.
<dl class="method">
<dt id="logging.DatagramHandler.emit">
<tt class="descname">emit</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.DatagramHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Pickles the record&#8217;s attribute dictionary and writes it to the socket in
binary format. If there is an error with the socket, silently drops the
packet. To unpickle the record at the receiving end into a
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a>, use the <a title="logging.makeLogRecord" class="reference internal" href="#logging.makeLogRecord"><tt class="xref docutils literal">makeLogRecord()</tt></a> function.</dd></dl>

<dl class="method">
<dt id="logging.DatagramHandler.makeSocket">
<tt class="descname">makeSocket</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.DatagramHandler.makeSocket" title="Permalink to this definition">¶</a></dt>
<dd>The factory method of <a title="logging.SocketHandler" class="reference internal" href="#logging.SocketHandler"><tt class="xref docutils literal">SocketHandler</tt></a> is here overridden to create
a UDP socket (<a title="socket.SOCK_DGRAM" class="reference external" href="socket.html#socket.SOCK_DGRAM"><tt class="xref docutils literal">socket.SOCK_DGRAM</tt></a>).</dd></dl>

<dl class="method">
<dt id="logging.DatagramHandler.send">
<tt class="descname">send</tt><big>(</big>s<big>)</big><a class="headerlink" href="#logging.DatagramHandler.send" title="Permalink to this definition">¶</a></dt>
<dd>Send a pickled string to a socket.</dd></dl>

</dd></dl>

</div>
<div class="section" id="sysloghandler">
<h3>15.6.14.8. SysLogHandler<a class="headerlink" href="#sysloghandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.SysLogHandler" class="reference internal" href="#logging.SysLogHandler"><tt class="xref docutils literal">SysLogHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt> module,
supports sending logging messages to a remote or local Unix syslog.
<dl class="class">
<dt id="logging.SysLogHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">SysLogHandler</tt><big>(</big>[address[, facility]]<big>)</big><a class="headerlink" href="#logging.SysLogHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.SysLogHandler" class="reference internal" href="#logging.SysLogHandler"><tt class="xref docutils literal">SysLogHandler</tt></a> class intended to
communicate with a remote Unix machine whose address is given by address in
the form of a <tt class="docutils literal">(host, port)</tt> tuple. If address is not specified,
<tt class="docutils literal">('localhost', 514)</tt> is used. The address is used to open a UDP socket. An
alternative to providing a <tt class="docutils literal">(host, port)</tt> tuple is providing an address as a
string, for example &#8220;/dev/log&#8221;. In this case, a Unix domain socket is used to
send the message to the syslog. If facility is not specified,
<tt class="xref docutils literal">LOG_USER</tt> is used.
<dl class="method">
<dt id="logging.SysLogHandler.close">
<tt class="descname">close</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.SysLogHandler.close" title="Permalink to this definition">¶</a></dt>
<dd>Closes the socket to the remote host.</dd></dl>

<dl class="method">
<dt id="logging.SysLogHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.SysLogHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>The record is formatted, and then sent to the syslog server. If exception
information is present, it is not sent to the server.</dd></dl>

<dl class="method">
<dt id="logging.SysLogHandler.encodePriority">
<tt class="descname">encodePriority</tt><big>(</big>facility, priority<big>)</big><a class="headerlink" href="#logging.SysLogHandler.encodePriority" title="Permalink to this definition">¶</a></dt>
<dd>Encodes the facility and priority into an integer. You can pass in strings
or integers - if strings are passed, internal mapping dictionaries are
used to convert them to integers.
The symbolic <tt class="docutils literal">LOG_</tt> values are defined in <a title="logging.SysLogHandler" class="reference internal" href="#logging.SysLogHandler"><tt class="xref docutils literal">SysLogHandler</tt></a> and
mirror the values defined in the <tt class="docutils literal">sys/syslog.h</tt> header file.
Priorities
<table border="1" class="docutils">
<colgroup>
<col width="63%" />
<col width="37%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Name (string)</th>
<th class="head">Symbolic value</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">alert</tt></td>
<td>LOG_ALERT</td>
</tr>
<tr><td><tt class="docutils literal">crit</tt> or <tt class="docutils literal">critical</tt></td>
<td>LOG_CRIT</td>
</tr>
<tr><td><tt class="docutils literal">debug</tt></td>
<td>LOG_DEBUG</td>
</tr>
<tr><td><tt class="docutils literal">emerg</tt> or <tt class="docutils literal">panic</tt></td>
<td>LOG_EMERG</td>
</tr>
<tr><td><tt class="docutils literal">err</tt> or <tt class="docutils literal">error</tt></td>
<td>LOG_ERR</td>
</tr>
<tr><td><tt class="docutils literal">info</tt></td>
<td>LOG_INFO</td>
</tr>
<tr><td><tt class="docutils literal">notice</tt></td>
<td>LOG_NOTICE</td>
</tr>
<tr><td><tt class="docutils literal">warn</tt> or <tt class="docutils literal">warning</tt></td>
<td>LOG_WARNING</td>
</tr>
</tbody>
</table>
Facilities
<table border="1" class="docutils">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Name (string)</th>
<th class="head">Symbolic value</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">auth</tt></td>
<td>LOG_AUTH</td>
</tr>
<tr><td><tt class="docutils literal">authpriv</tt></td>
<td>LOG_AUTHPRIV</td>
</tr>
<tr><td><tt class="docutils literal">cron</tt></td>
<td>LOG_CRON</td>
</tr>
<tr><td><tt class="docutils literal">daemon</tt></td>
<td>LOG_DAEMON</td>
</tr>
<tr><td><tt class="docutils literal">ftp</tt></td>
<td>LOG_FTP</td>
</tr>
<tr><td><tt class="docutils literal">kern</tt></td>
<td>LOG_KERN</td>
</tr>
<tr><td><tt class="docutils literal">lpr</tt></td>
<td>LOG_LPR</td>
</tr>
<tr><td><tt class="docutils literal">mail</tt></td>
<td>LOG_MAIL</td>
</tr>
<tr><td><tt class="docutils literal">news</tt></td>
<td>LOG_NEWS</td>
</tr>
<tr><td><tt class="docutils literal">syslog</tt></td>
<td>LOG_SYSLOG</td>
</tr>
<tr><td><tt class="docutils literal">user</tt></td>
<td>LOG_USER</td>
</tr>
<tr><td><tt class="docutils literal">uucp</tt></td>
<td>LOG_UUCP</td>
</tr>
<tr><td><tt class="docutils literal">local0</tt></td>
<td>LOG_LOCAL0</td>
</tr>
<tr><td><tt class="docutils literal">local1</tt></td>
<td>LOG_LOCAL1</td>
</tr>
<tr><td><tt class="docutils literal">local2</tt></td>
<td>LOG_LOCAL2</td>
</tr>
<tr><td><tt class="docutils literal">local3</tt></td>
<td>LOG_LOCAL3</td>
</tr>
<tr><td><tt class="docutils literal">local4</tt></td>
<td>LOG_LOCAL4</td>
</tr>
<tr><td><tt class="docutils literal">local5</tt></td>
<td>LOG_LOCAL5</td>
</tr>
<tr><td><tt class="docutils literal">local6</tt></td>
<td>LOG_LOCAL6</td>
</tr>
<tr><td><tt class="docutils literal">local7</tt></td>
<td>LOG_LOCAL7</td>
</tr>
</tbody>
</table>
</dd></dl>

<dl class="method">
<dt id="logging.SysLogHandler.mapPriority">
<tt class="descname">mapPriority</tt><big>(</big>levelname<big>)</big><a class="headerlink" href="#logging.SysLogHandler.mapPriority" title="Permalink to this definition">¶</a></dt>
<dd>Maps a logging level name to a syslog priority name.
You may need to override this if you are using custom levels, or
if the default algorithm is not suitable for your needs. The
default algorithm maps <tt class="docutils literal">DEBUG</tt>, <tt class="docutils literal">INFO</tt>, <tt class="docutils literal">WARNING</tt>, <tt class="docutils literal">ERROR</tt> and
<tt class="docutils literal">CRITICAL</tt> to the equivalent syslog names, and all other level
names to &#8220;warning&#8221;.</dd></dl>

</dd></dl>

</div>
<div class="section" id="nteventloghandler">
<h3>15.6.14.9. NTEventLogHandler<a class="headerlink" href="#nteventloghandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.NTEventLogHandler" class="reference internal" href="#logging.NTEventLogHandler"><tt class="xref docutils literal">NTEventLogHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt>
module, supports sending logging messages to a local Windows NT, Windows 2000 or
Windows XP event log. Before you can use it, you need Mark Hammond&#8217;s Win32
extensions for Python installed.
<dl class="class">
<dt id="logging.NTEventLogHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">NTEventLogHandler</tt><big>(</big>appname[, dllname[, logtype]]<big>)</big><a class="headerlink" href="#logging.NTEventLogHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.NTEventLogHandler" class="reference internal" href="#logging.NTEventLogHandler"><tt class="xref docutils literal">NTEventLogHandler</tt></a> class. The appname is
used to define the application name as it appears in the event log. An
appropriate registry entry is created using this name. The dllname should give
the fully qualified pathname of a .dll or .exe which contains message
definitions to hold in the log (if not specified, <tt class="docutils literal">'win32service.pyd'</tt> is used
- this is installed with the Win32 extensions and contains some basic
placeholder message definitions. Note that use of these placeholders will make
your event logs big, as the entire message source is held in the log. If you
want slimmer logs, you have to pass in the name of your own .dll or .exe which
contains the message definitions you want to use in the event log). The
logtype is one of <tt class="docutils literal">'Application'</tt>, <tt class="docutils literal">'System'</tt> or <tt class="docutils literal">'Security'</tt>, and
defaults to <tt class="docutils literal">'Application'</tt>.
<dl class="method">
<dt id="logging.NTEventLogHandler.close">
<tt class="descname">close</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.NTEventLogHandler.close" title="Permalink to this definition">¶</a></dt>
<dd>At this point, you can remove the application name from the registry as a
source of event log entries. However, if you do this, you will not be able
to see the events as you intended in the Event Log Viewer - it needs to be
able to access the registry to get the .dll name. The current version does
not do this.</dd></dl>

<dl class="method">
<dt id="logging.NTEventLogHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.NTEventLogHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Determines the message ID, event category and event type, and then logs
the message in the NT event log.</dd></dl>

<dl class="method">
<dt id="logging.NTEventLogHandler.getEventCategory">
<tt class="descname">getEventCategory</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.NTEventLogHandler.getEventCategory" title="Permalink to this definition">¶</a></dt>
<dd>Returns the event category for the record. Override this if you want to
specify your own categories. This version returns 0.</dd></dl>

<dl class="method">
<dt id="logging.NTEventLogHandler.getEventType">
<tt class="descname">getEventType</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.NTEventLogHandler.getEventType" title="Permalink to this definition">¶</a></dt>
<dd>Returns the event type for the record. Override this if you want to
specify your own types. This version does a mapping using the handler&#8217;s
typemap attribute, which is set up in <a title="object.__init__" class="reference external" href="../reference/datamodel.html#object.__init__"><tt class="xref docutils literal">__init__()</tt></a> to a dictionary
which contains mappings for <tt class="xref docutils literal">DEBUG</tt>, <tt class="xref docutils literal">INFO</tt>,
<tt class="xref docutils literal">WARNING</tt>, <tt class="xref docutils literal">ERROR</tt> and <tt class="xref docutils literal">CRITICAL</tt>. If you are using
your own levels, you will either need to override this method or place a
suitable dictionary in the handler&#8217;s typemap attribute.</dd></dl>

<dl class="method">
<dt id="logging.NTEventLogHandler.getMessageID">
<tt class="descname">getMessageID</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.NTEventLogHandler.getMessageID" title="Permalink to this definition">¶</a></dt>
<dd>Returns the message ID for the record. If you are using your own messages,
you could do this by having the msg passed to the logger being an ID
rather than a format string. Then, in here, you could use a dictionary
lookup to get the message ID. This version returns 1, which is the base
message ID in <tt class="docutils literal">win32service.pyd</tt>.</dd></dl>

</dd></dl>

</div>
<div class="section" id="smtphandler">
<h3>15.6.14.10. SMTPHandler<a class="headerlink" href="#smtphandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.SMTPHandler" class="reference internal" href="#logging.SMTPHandler"><tt class="xref docutils literal">SMTPHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt> module,
supports sending logging messages to an email address via SMTP.
<dl class="class">
<dt id="logging.SMTPHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">SMTPHandler</tt><big>(</big>mailhost, fromaddr, toaddrs, subject[, credentials]<big>)</big><a class="headerlink" href="#logging.SMTPHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.SMTPHandler" class="reference internal" href="#logging.SMTPHandler"><tt class="xref docutils literal">SMTPHandler</tt></a> class. The instance is
initialized with the from and to addresses and subject line of the email. The
toaddrs should be a list of strings. To specify a non-standard SMTP port, use
the (host, port) tuple format for the mailhost argument. If you use a string,
the standard SMTP port is used. If your SMTP server requires authentication, you
can specify a (username, password) tuple for the credentials argument.

Changed in version 2.6: credentials was added.
<dl class="method">
<dt id="logging.SMTPHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.SMTPHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Formats the record and sends it to the specified addressees.</dd></dl>

<dl class="method">
<dt id="logging.SMTPHandler.getSubject">
<tt class="descname">getSubject</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.SMTPHandler.getSubject" title="Permalink to this definition">¶</a></dt>
<dd>If you want to specify a subject line which is record-dependent, override
this method.</dd></dl>

</dd></dl>

</div>
<div class="section" id="memoryhandler">
<h3>15.6.14.11. MemoryHandler<a class="headerlink" href="#memoryhandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.MemoryHandler" class="reference internal" href="#logging.MemoryHandler"><tt class="xref docutils literal">MemoryHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt> module,
supports buffering of logging records in memory, periodically flushing them to a
target handler. Flushing occurs whenever the buffer is full, or when an
event of a certain severity or greater is seen.
<a title="logging.MemoryHandler" class="reference internal" href="#logging.MemoryHandler"><tt class="xref docutils literal">MemoryHandler</tt></a> is a subclass of the more general
<a title="logging.BufferingHandler" class="reference internal" href="#logging.BufferingHandler"><tt class="xref docutils literal">BufferingHandler</tt></a>, which is an abstract class. This buffers logging
records in memory. Whenever each record is added to the buffer, a check is made
by calling <tt class="xref docutils literal">shouldFlush()</tt> to see if the buffer should be flushed. If it
should, then <tt class="xref docutils literal">flush()</tt> is expected to do the needful.
<dl class="class">
<dt id="logging.BufferingHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">BufferingHandler</tt><big>(</big>capacity<big>)</big><a class="headerlink" href="#logging.BufferingHandler" title="Permalink to this definition">¶</a></dt>
<dd>Initializes the handler with a buffer of the specified capacity.
<dl class="method">
<dt id="logging.BufferingHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.BufferingHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Appends the record to the buffer. If <a title="logging.BufferingHandler.shouldFlush" class="reference internal" href="#logging.BufferingHandler.shouldFlush"><tt class="xref docutils literal">shouldFlush()</tt></a> returns true,
calls <a title="logging.BufferingHandler.flush" class="reference internal" href="#logging.BufferingHandler.flush"><tt class="xref docutils literal">flush()</tt></a> to process the buffer.</dd></dl>

<dl class="method">
<dt id="logging.BufferingHandler.flush">
<tt class="descname">flush</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.BufferingHandler.flush" title="Permalink to this definition">¶</a></dt>
<dd>You can override this to implement custom flushing behavior. This version
just zaps the buffer to empty.</dd></dl>

<dl class="method">
<dt id="logging.BufferingHandler.shouldFlush">
<tt class="descname">shouldFlush</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.BufferingHandler.shouldFlush" title="Permalink to this definition">¶</a></dt>
<dd>Returns true if the buffer is up to capacity. This method can be
overridden to implement custom flushing strategies.</dd></dl>

</dd></dl>

<dl class="class">
<dt id="logging.MemoryHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">MemoryHandler</tt><big>(</big>capacity[, flushLevel[, target]]<big>)</big><a class="headerlink" href="#logging.MemoryHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.MemoryHandler" class="reference internal" href="#logging.MemoryHandler"><tt class="xref docutils literal">MemoryHandler</tt></a> class. The instance is
initialized with a buffer size of capacity. If flushLevel is not specified,
<tt class="xref docutils literal">ERROR</tt> is used. If no target is specified, the target will need to be
set using <a title="logging.MemoryHandler.setTarget" class="reference internal" href="#logging.MemoryHandler.setTarget"><tt class="xref docutils literal">setTarget()</tt></a> before this handler does anything useful.
<dl class="method">
<dt id="logging.MemoryHandler.close">
<tt class="descname">close</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.MemoryHandler.close" title="Permalink to this definition">¶</a></dt>
<dd>Calls <a title="logging.MemoryHandler.flush" class="reference internal" href="#logging.MemoryHandler.flush"><tt class="xref docutils literal">flush()</tt></a>, sets the target to <a title="None" class="reference external" href="constants.html#None"><tt class="xref xref docutils literal">None</tt></a> and clears the
buffer.</dd></dl>

<dl class="method">
<dt id="logging.MemoryHandler.flush">
<tt class="descname">flush</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.MemoryHandler.flush" title="Permalink to this definition">¶</a></dt>
<dd>For a <a title="logging.MemoryHandler" class="reference internal" href="#logging.MemoryHandler"><tt class="xref docutils literal">MemoryHandler</tt></a>, flushing means just sending the buffered
records to the target, if there is one. Override if you want different
behavior.</dd></dl>

<dl class="method">
<dt id="logging.MemoryHandler.setTarget">
<tt class="descname">setTarget</tt><big>(</big>target<big>)</big><a class="headerlink" href="#logging.MemoryHandler.setTarget" title="Permalink to this definition">¶</a></dt>
<dd>Sets the target handler for this handler.</dd></dl>

<dl class="method">
<dt id="logging.MemoryHandler.shouldFlush">
<tt class="descname">shouldFlush</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.MemoryHandler.shouldFlush" title="Permalink to this definition">¶</a></dt>
<dd>Checks for buffer full or a record at the flushLevel or higher.</dd></dl>

</dd></dl>

</div>
<div class="section" id="httphandler">
<h3>15.6.14.12. HTTPHandler<a class="headerlink" href="#httphandler" title="Permalink to this headline">¶</a></h3>
The <a title="logging.HTTPHandler" class="reference internal" href="#logging.HTTPHandler"><tt class="xref docutils literal">HTTPHandler</tt></a> class, located in the <tt class="xref docutils literal">logging.handlers</tt> module,
supports sending logging messages to a Web server, using either <tt class="docutils literal">GET</tt> or
<tt class="docutils literal">POST</tt> semantics.
<dl class="class">
<dt id="logging.HTTPHandler">
class <tt class="descclassname">logging.</tt><tt class="descname">HTTPHandler</tt><big>(</big>host, url[, method]<big>)</big><a class="headerlink" href="#logging.HTTPHandler" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.HTTPHandler" class="reference internal" href="#logging.HTTPHandler"><tt class="xref docutils literal">HTTPHandler</tt></a> class. The instance is
initialized with a host address, url and HTTP method. The host can be of the
form <tt class="docutils literal">host:port</tt>, should you need to use a specific port number. If no
method is specified, <tt class="docutils literal">GET</tt> is used.
<dl class="method">
<dt id="logging.HTTPHandler.emit">
<tt class="descname">emit</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.HTTPHandler.emit" title="Permalink to this definition">¶</a></dt>
<dd>Sends the record to the Web server as an URL-encoded dictionary.</dd></dl>

</dd></dl>

</div>
</div>
<div class="section" id="formatter-objects">
<h2>15.6.15. Formatter Objects<a class="headerlink" href="#formatter-objects" title="Permalink to this headline">¶</a></h2>
<a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a>s have the following attributes and methods. They are
responsible for converting a <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> to (usually) a string which can
be interpreted by either a human or an external system. The base
<a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> allows a formatting string to be specified. If none is
supplied, the default value of <tt class="docutils literal">'%(message)s'</tt> is used.
A Formatter can be initialized with a format string which makes use of knowledge
of the <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> attributes - such as the default value mentioned above
making use of the fact that the user&#8217;s message and arguments are pre-formatted
into a <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a>&#8216;s message attribute. This format string contains
standard Python %-style mapping keys. See section <a class="reference external" href="stdtypes.html#string-formatting">String Formatting Operations</a>
for more information on string formatting.
Currently, the useful mapping keys in a <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> are:
<table border="1" class="docutils">
<colgroup>
<col width="35%" />
<col width="65%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Format</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal">%(name)s</tt></td>
<td>Name of the logger (logging channel).</td>
</tr>
<tr><td><tt class="docutils literal">%(levelno)s</tt></td>
<td>Numeric logging level for the message
(<tt class="xref docutils literal">DEBUG</tt>, <tt class="xref docutils literal">INFO</tt>,
<tt class="xref docutils literal">WARNING</tt>, <tt class="xref docutils literal">ERROR</tt>,
<tt class="xref docutils literal">CRITICAL</tt>).</td>
</tr>
<tr><td><tt class="docutils literal">%(levelname)s</tt></td>
<td>Text logging level for the message
(<tt class="docutils literal">'DEBUG'</tt>, <tt class="docutils literal">'INFO'</tt>, <tt class="docutils literal">'WARNING'</tt>,
<tt class="docutils literal">'ERROR'</tt>, <tt class="docutils literal">'CRITICAL'</tt>).</td>
</tr>
<tr><td><tt class="docutils literal">%(pathname)s</tt></td>
<td>Full pathname of the source file where the
logging call was issued (if available).</td>
</tr>
<tr><td><tt class="docutils literal">%(filename)s</tt></td>
<td>Filename portion of pathname.</td>
</tr>
<tr><td><tt class="docutils literal">%(module)s</tt></td>
<td>Module (name portion of filename).</td>
</tr>
<tr><td><tt class="docutils literal">%(funcName)s</tt></td>
<td>Name of function containing the logging call.</td>
</tr>
<tr><td><tt class="docutils literal">%(lineno)d</tt></td>
<td>Source line number where the logging call was
issued (if available).</td>
</tr>
<tr><td><tt class="docutils literal">%(created)f</tt></td>
<td>Time when the <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> was created
(as returned by <a title="time.time" class="reference external" href="time.html#time.time"><tt class="xref docutils literal">time.time()</tt></a>).</td>
</tr>
<tr><td><tt class="docutils literal">%(relativeCreated)d</tt></td>
<td>Time in milliseconds when the LogRecord was
created, relative to the time the logging
module was loaded.</td>
</tr>
<tr><td><tt class="docutils literal">%(asctime)s</tt></td>
<td>Human-readable time when the
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> was created. By default
this is of the form &#8220;2003-07-08 16:49:45,896&#8221;
(the numbers after the comma are millisecond
portion of the time).</td>
</tr>
<tr><td><tt class="docutils literal">%(msecs)d</tt></td>
<td>Millisecond portion of the time when the
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> was created.</td>
</tr>
<tr><td><tt class="docutils literal">%(thread)d</tt></td>
<td>Thread ID (if available).</td>
</tr>
<tr><td><tt class="docutils literal">%(threadName)s</tt></td>
<td>Thread name (if available).</td>
</tr>
<tr><td><tt class="docutils literal">%(process)d</tt></td>
<td>Process ID (if available).</td>
</tr>
<tr><td><tt class="docutils literal">%(message)s</tt></td>
<td>The logged message, computed as <tt class="docutils literal">msg %
args</tt>.</td>
</tr>
</tbody>
</table>

Changed in version 2.5: funcName was added.
<dl class="class">
<dt id="logging.Formatter">
class <tt class="descclassname">logging.</tt><tt class="descname">Formatter</tt><big>(</big>[fmt[, datefmt]]<big>)</big><a class="headerlink" href="#logging.Formatter" title="Permalink to this definition">¶</a></dt>
<dd>Returns a new instance of the <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> 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,
<tt class="docutils literal">'%(message)s'</tt> is used. If no datefmt is specified, the ISO8601 date format
is used.
<dl class="method">
<dt id="logging.Formatter.format">
<tt class="descname">format</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Formatter.format" title="Permalink to this definition">¶</a></dt>
<dd>The record&#8217;s attribute dictionary is used as the operand to a string
formatting operation. Returns the resulting string. Before formatting the
dictionary, a couple of preparatory steps are carried out. The message
attribute of the record is computed using msg % args. If the
formatting string contains <tt class="docutils literal">'(asctime)'</tt>, <a title="logging.Formatter.formatTime" class="reference internal" href="#logging.Formatter.formatTime"><tt class="xref docutils literal">formatTime()</tt></a> is called
to format the event time. If there is exception information, it is
formatted using <a title="logging.Formatter.formatException" class="reference internal" href="#logging.Formatter.formatException"><tt class="xref docutils literal">formatException()</tt></a> and appended to the message. Note
that the formatted exception information is cached in attribute
exc_text. This is useful because the exception information can be
pickled and sent across the wire, but you should be careful if you have
more than one <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> subclass which customizes the formatting
of exception information. In this case, you will have to clear the cached
value after a formatter has done its formatting, so that the next
formatter to handle the event doesn&#8217;t use the cached value but
recalculates it afresh.</dd></dl>

<dl class="method">
<dt id="logging.Formatter.formatTime">
<tt class="descname">formatTime</tt><big>(</big>record[, datefmt]<big>)</big><a class="headerlink" href="#logging.Formatter.formatTime" title="Permalink to this definition">¶</a></dt>
<dd>This method should be called from <a title="format" class="reference external" href="functions.html#format"><tt class="xref docutils literal">format()</tt></a> by a formatter which
wants to make use of a formatted time. This method can be overridden in
formatters to provide for any specific requirement, but the basic behavior
is as follows: if datefmt (a string) is specified, it is used with
<a title="time.strftime" class="reference external" href="time.html#time.strftime"><tt class="xref docutils literal">time.strftime()</tt></a> to format the creation time of the
record. Otherwise, the ISO8601 format is used. The resulting string is
returned.</dd></dl>

<dl class="method">
<dt id="logging.Formatter.formatException">
<tt class="descname">formatException</tt><big>(</big>exc_info<big>)</big><a class="headerlink" href="#logging.Formatter.formatException" title="Permalink to this definition">¶</a></dt>
<dd>Formats the specified exception information (a standard exception tuple as
returned by <a title="sys.exc_info" class="reference external" href="sys.html#sys.exc_info"><tt class="xref docutils literal">sys.exc_info()</tt></a>) as a string. This default implementation
just uses <a title="traceback.print_exception" class="reference external" href="traceback.html#traceback.print_exception"><tt class="xref docutils literal">traceback.print_exception()</tt></a>. The resulting string is
returned.</dd></dl>

</dd></dl>

</div>
<div class="section" id="filter-objects">
<h2>15.6.16. Filter Objects<a class="headerlink" href="#filter-objects" title="Permalink to this headline">¶</a></h2>
Filters can be used by <tt class="xref docutils literal">Handler</tt>s and <tt class="xref docutils literal">Logger</tt>s 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 &#8220;A.B&#8221; will allow events logged by loggers
&#8220;A.B&#8221;, &#8220;A.B.C&#8221;, &#8220;A.B.C.D&#8221;, &#8220;A.B.D&#8221; etc. but not &#8220;A.BB&#8221;, &#8220;B.A.B&#8221; etc. If
initialized with the empty string, all events are passed.
<dl class="class">
<dt id="logging.Filter">
class <tt class="descclassname">logging.</tt><tt class="descname">Filter</tt><big>(</big>[name]<big>)</big><a class="headerlink" href="#logging.Filter" title="Permalink to this definition">¶</a></dt>
<dd>Returns an instance of the <a title="logging.Filter" class="reference internal" href="#logging.Filter"><tt class="xref docutils literal">Filter</tt></a> class. If name is specified, it
names a logger which, together with its children, will have its events allowed
through the filter. If no name is specified, allows every event.
<dl class="method">
<dt id="logging.Filter.filter">
<tt class="descname">filter</tt><big>(</big>record<big>)</big><a class="headerlink" href="#logging.Filter.filter" title="Permalink to this definition">¶</a></dt>
<dd>Is the specified record to be logged? Returns zero for no, nonzero for
yes. If deemed appropriate, the record may be modified in-place by this
method.</dd></dl>

</dd></dl>

</div>
<div class="section" id="logrecord-objects">
<h2>15.6.17. LogRecord Objects<a class="headerlink" href="#logrecord-objects" title="Permalink to this headline">¶</a></h2>
<a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instances are created every time something is logged. They
contain all the information pertinent to the event being logged. The main
information passed in is in msg and args, which are combined using msg % args to
create the message field of the record. The record also includes information
such as when the record was created, the source line where the logging call was
made, and any exception information to be logged.
<dl class="class">
<dt id="logging.LogRecord">
class <tt class="descclassname">logging.</tt><tt class="descname">LogRecord</tt><big>(</big>name, lvl, pathname, lineno, msg, args, exc_info[, func]<big>)</big><a class="headerlink" href="#logging.LogRecord" title="Permalink to this definition">¶</a></dt>
<dd>Returns an instance of <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> initialized with interesting
information. The name is the logger name; lvl is the numeric level;
pathname is the absolute pathname of the source file in which the logging
call was made; lineno is the line number in that file where the logging
call is found; msg is the user-supplied message (a format string); args
is the tuple which, together with msg, makes up the user message; and
exc_info is the exception tuple obtained by calling <a title="sys.exc_info" class="reference external" href="sys.html#sys.exc_info"><tt class="xref docutils literal">sys.exc_info()</tt></a>
(or <a title="None" class="reference external" href="constants.html#None"><tt class="xref xref docutils literal">None</tt></a>, if no exception information is available). The func is
the name of the function from which the logging call was made. If not
specified, it defaults to <tt class="xref docutils literal">None</tt>.

Changed in version 2.5: func was added.
<dl class="method">
<dt id="logging.LogRecord.getMessage">
<tt class="descname">getMessage</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.LogRecord.getMessage" title="Permalink to this definition">¶</a></dt>
<dd>Returns the message for this <a title="logging.LogRecord" class="reference internal" href="#logging.LogRecord"><tt class="xref docutils literal">LogRecord</tt></a> instance after merging any
user-supplied arguments with the message.</dd></dl>

</dd></dl>

</div>
<div class="section" id="loggeradapter-objects">
<h2>15.6.18. LoggerAdapter Objects<a class="headerlink" href="#loggeradapter-objects" title="Permalink to this headline">¶</a></h2>

New in version 2.6.
<a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a> instances are used to conveniently pass contextual
information into logging calls. For a usage example , see the section on
<a class="reference internal" href="#context-info">adding contextual information to your logging output</a>.
<dl class="class">
<dt id="logging.LoggerAdapter">
class <tt class="descclassname">logging.</tt><tt class="descname">LoggerAdapter</tt><big>(</big>logger, extra<big>)</big><a class="headerlink" href="#logging.LoggerAdapter" title="Permalink to this definition">¶</a></dt>
<dd>Returns an instance of <a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a> initialized with an
underlying <tt class="xref docutils literal">Logger</tt> instance and a dict-like object.
<dl class="method">
<dt id="logging.LoggerAdapter.process">
<tt class="descname">process</tt><big>(</big>msg, kwargs<big>)</big><a class="headerlink" href="#logging.LoggerAdapter.process" title="Permalink to this definition">¶</a></dt>
<dd>Modifies the message and/or keyword arguments passed to a logging call in
order to insert contextual information. This implementation takes the object
passed as extra to the constructor and adds it to kwargs using key
&#8216;extra&#8217;. The return value is a (msg, kwargs) tuple which has the
(possibly modified) versions of the arguments passed in.</dd></dl>

</dd></dl>

In addition to the above, <a title="logging.LoggerAdapter" class="reference internal" href="#logging.LoggerAdapter"><tt class="xref docutils literal">LoggerAdapter</tt></a> supports all the logging
methods of <tt class="xref docutils literal">Logger</tt>, i.e. <a title="logging.debug" class="reference internal" href="#logging.debug"><tt class="xref docutils literal">debug()</tt></a>, <a title="logging.info" class="reference internal" href="#logging.info"><tt class="xref docutils literal">info()</tt></a>, <a title="logging.warning" class="reference internal" href="#logging.warning"><tt class="xref docutils literal">warning()</tt></a>,
<a title="logging.error" class="reference internal" href="#logging.error"><tt class="xref docutils literal">error()</tt></a>, <a title="logging.exception" class="reference internal" href="#logging.exception"><tt class="xref docutils literal">exception()</tt></a>, <a title="logging.critical" class="reference internal" href="#logging.critical"><tt class="xref docutils literal">critical()</tt></a> and <a title="logging.log" class="reference internal" href="#logging.log"><tt class="xref docutils literal">log()</tt></a>. These
methods have the same signatures as their counterparts in <tt class="xref docutils literal">Logger</tt>, so
you can use the two types of instances interchangeably.
</div>
<div class="section" id="thread-safety">
<h2>15.6.19. Thread Safety<a class="headerlink" href="#thread-safety" title="Permalink to this headline">¶</a></h2>
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&#8217;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 <a title="Set handlers for asynchronous events." class="reference external" href="signal.html#module-signal"><tt class="xref docutils literal">signal</tt></a>
module, you may not be able to use logging from within such handlers. This is
because lock implementations in the <a title="Higher-level threading interface." class="reference external" href="threading.html#module-threading"><tt class="xref docutils literal">threading</tt></a> module are not always
re-entrant, and so cannot be invoked from such signal handlers.
</div>
<div class="section" id="configuration">
<h2>15.6.20. Configuration<a class="headerlink" href="#configuration" title="Permalink to this headline">¶</a></h2>
<div class="section" id="configuration-functions">
<h3>15.6.20.1. Configuration functions<a class="headerlink" href="#configuration-functions" title="Permalink to this headline">¶</a></h3>
The following functions configure the logging module. They are located in the
<tt class="xref docutils literal">logging.config</tt> module. Their use is optional &#8212; you can configure the
logging module using these functions or by making calls to the main API (defined
in <tt class="xref docutils literal">logging</tt> itself) and defining handlers which are declared either in
<tt class="xref docutils literal">logging</tt> or <tt class="xref docutils literal">logging.handlers</tt>.
<dl class="function">
<dt id="logging.fileConfig">
<tt class="descclassname">logging.</tt><tt class="descname">fileConfig</tt><big>(</big>fname[, defaults]<big>)</big><a class="headerlink" href="#logging.fileConfig" title="Permalink to this definition">¶</a></dt>
<dd>Reads the logging configuration from a ConfigParser-format file named fname.
This function can be called several times from an application, allowing an end
user the ability to select from various pre-canned configurations (if the
developer provides a mechanism to present the choices and load the chosen
configuration). Defaults to be passed to ConfigParser can be specified in the
defaults argument.</dd></dl>

<dl class="function">
<dt id="logging.listen">
<tt class="descclassname">logging.</tt><tt class="descname">listen</tt><big>(</big>[port]<big>)</big><a class="headerlink" href="#logging.listen" title="Permalink to this definition">¶</a></dt>
<dd>Starts up a socket server on the specified port, and listens for new
configurations. If no port is specified, the module&#8217;s default
<tt class="xref docutils literal">DEFAULT_LOGGING_CONFIG_PORT</tt> is used. Logging configurations will be
sent as a file suitable for processing by <a title="logging.fileConfig" class="reference internal" href="#logging.fileConfig"><tt class="xref docutils literal">fileConfig()</tt></a>. Returns a
<tt class="xref docutils literal">Thread</tt> instance on which you can call <tt class="xref docutils literal">start()</tt> to start the
server, and which you can <tt class="xref docutils literal">join()</tt> when appropriate. To stop the server,
call <a title="logging.stopListening" class="reference internal" href="#logging.stopListening"><tt class="xref docutils literal">stopListening()</tt></a>.
To send a configuration to the socket, read in the configuration file and
send it to the socket as a string of bytes preceded by a four-byte length
string packed in binary using <tt class="docutils literal">struct.pack('&gt;L', n)</tt>.
</dd></dl>

<dl class="function">
<dt id="logging.stopListening">
<tt class="descclassname">logging.</tt><tt class="descname">stopListening</tt><big>(</big><big>)</big><a class="headerlink" href="#logging.stopListening" title="Permalink to this definition">¶</a></dt>
<dd>Stops the listening server which was created with a call to <a title="logging.listen" class="reference internal" href="#logging.listen"><tt class="xref docutils literal">listen()</tt></a>.
This is typically called before calling <tt class="xref docutils literal">join()</tt> on the return value from
<a title="logging.listen" class="reference internal" href="#logging.listen"><tt class="xref docutils literal">listen()</tt></a>.</dd></dl>

</div>
<div class="section" id="configuration-file-format">
<h3>15.6.20.2. Configuration file format<a class="headerlink" href="#configuration-file-format" title="Permalink to this headline">¶</a></h3>
The configuration file format understood by <a title="logging.fileConfig" class="reference internal" href="#logging.fileConfig"><tt class="xref docutils literal">fileConfig()</tt></a> is based on
<a title="Configuration file parser." class="reference external" href="configparser.html#module-ConfigParser"><tt class="xref docutils literal">ConfigParser</tt></a> functionality. The file must contain sections called
<tt class="docutils literal">[loggers]</tt>, <tt class="docutils literal">[handlers]</tt> and <tt class="docutils literal">[formatters]</tt> which identify by name the
entities of each type which are defined in the file. For each such entity,
there is a separate section which identifies how that entity is configured.
Thus, for a logger named <tt class="docutils literal">log01</tt> in the <tt class="docutils literal">[loggers]</tt> section, the relevant
configuration details are held in a section <tt class="docutils literal">[logger_log01]</tt>. Similarly, a
handler called <tt class="docutils literal">hand01</tt> in the <tt class="docutils literal">[handlers]</tt> section will have its
configuration held in a section called <tt class="docutils literal">[handler_hand01]</tt>, while a formatter
called <tt class="docutils literal">form01</tt> in the <tt class="docutils literal">[formatters]</tt> section will have its configuration
specified in a section called <tt class="docutils literal">[formatter_form01]</tt>. The root logger
configuration must be specified in a section called <tt class="docutils literal">[logger_root]</tt>.
Examples of these sections in the file are given below.
<div class="highlight-python"><div class="highlight"><pre>[loggers]
keys=root,log02,log03,log04,log05,log06,log07

[handlers]
keys=hand01,hand02,hand03,hand04,hand05,hand06,hand07,hand08,hand09

[formatters]
keys=form01,form02,form03,form04,form05,form06,form07,form08,form09
</pre></div>
</div>
The root logger must specify a level and a list of handlers. An example of a
root logger section is given below.
<div class="highlight-python"><div class="highlight"><pre>[logger_root]
level=NOTSET
handlers=hand01
</pre></div>
</div>
The <tt class="docutils literal">level</tt> entry can be one of <tt class="docutils literal">DEBUG, INFO, WARNING, ERROR, CRITICAL</tt> or
<tt class="docutils literal">NOTSET</tt>. For the root logger only, <tt class="docutils literal">NOTSET</tt> means that all messages will be
logged. Level values are <a title="eval" class="reference external" href="functions.html#eval"><tt class="xref docutils literal">eval()</tt></a>uated in the context of the <tt class="docutils literal">logging</tt>
package&#8217;s namespace.
The <tt class="docutils literal">handlers</tt> entry is a comma-separated list of handler names, which must
appear in the <tt class="docutils literal">[handlers]</tt> section. These names must appear in the
<tt class="docutils literal">[handlers]</tt> section and have corresponding sections in the configuration
file.
For loggers other than the root logger, some additional information is required.
This is illustrated by the following example.
<div class="highlight-python"><div class="highlight"><pre>[logger_parser]
level=DEBUG
handlers=hand01
propagate=1
qualname=compiler.parser
</pre></div>
</div>
The <tt class="docutils literal">level</tt> and <tt class="docutils literal">handlers</tt> entries are interpreted as for the root logger,
except that if a non-root logger&#8217;s level is specified as <tt class="docutils literal">NOTSET</tt>, the system
consults loggers higher up the hierarchy to determine the effective level of the
logger. The <tt class="docutils literal">propagate</tt> entry is set to 1 to indicate that messages must
propagate to handlers higher up the logger hierarchy from this logger, or 0 to
indicate that messages are not propagated to handlers up the hierarchy. The
<tt class="docutils literal">qualname</tt> entry is the hierarchical channel name of the logger, that is to
say the name used by the application to get the logger.
Sections which specify handler configuration are exemplified by the following.
<div class="highlight-python"><pre>[handler_hand01]
class=StreamHandler
level=NOTSET
formatter=form01
args=(sys.stdout,)</pre>
</div>
The <tt class="docutils literal">class</tt> entry indicates the handler&#8217;s class (as determined by <a title="eval" class="reference external" href="functions.html#eval"><tt class="xref docutils literal">eval()</tt></a>
in the <tt class="docutils literal">logging</tt> package&#8217;s namespace). The <tt class="docutils literal">level</tt> is interpreted as for
loggers, and <tt class="docutils literal">NOTSET</tt> is taken to mean &#8220;log everything&#8221;.

Changed in version 2.6: Added support for resolving the handler&#8217;s class as a dotted module and class
name.
The <tt class="docutils literal">formatter</tt> entry indicates the key name of the formatter for this
handler. If blank, a default formatter (<tt class="docutils literal">logging._defaultFormatter</tt>) is used.
If a name is specified, it must appear in the <tt class="docutils literal">[formatters]</tt> section and have
a corresponding section in the configuration file.
The <tt class="docutils literal">args</tt> entry, when <a title="eval" class="reference external" href="functions.html#eval"><tt class="xref docutils literal">eval()</tt></a>uated in the context of the <tt class="docutils literal">logging</tt>
package&#8217;s namespace, is the list of arguments to the constructor for the handler
class. Refer to the constructors for the relevant handlers, or to the examples
below, to see how typical entries are constructed.
<div class="highlight-python"><pre>[handler_hand02]
class=FileHandler
level=DEBUG
formatter=form02
args=('python.log', 'w')

[handler_hand03]
class=handlers.SocketHandler
level=INFO
formatter=form03
args=('localhost', handlers.DEFAULT_TCP_LOGGING_PORT)

[handler_hand04]
class=handlers.DatagramHandler
level=WARN
formatter=form04
args=('localhost', handlers.DEFAULT_UDP_LOGGING_PORT)

[handler_hand05]
class=handlers.SysLogHandler
level=ERROR
formatter=form05
args=(('localhost', handlers.SYSLOG_UDP_PORT), handlers.SysLogHandler.LOG_USER)

[handler_hand06]
class=handlers.NTEventLogHandler
level=CRITICAL
formatter=form06
args=('Python Application', '', 'Application')

[handler_hand07]
class=handlers.SMTPHandler
level=WARN
formatter=form07
args=('localhost', 'from@abc', ['user1@abc', 'user2@xyz'], 'Logger Subject')

[handler_hand08]
class=handlers.MemoryHandler
level=NOTSET
formatter=form08
target=
args=(10, ERROR)

[handler_hand09]
class=handlers.HTTPHandler
level=NOTSET
formatter=form09
args=('localhost:9022', '/log', 'GET')</pre>
</div>
Sections which specify formatter configuration are typified by the following.
<div class="highlight-python"><pre>[formatter_form01]
format=F1 %(asctime)s %(levelname)s %(message)s
datefmt=
class=logging.Formatter</pre>
</div>
The <tt class="docutils literal">format</tt> entry is the overall format string, and the <tt class="docutils literal">datefmt</tt> entry is
the <tt class="xref docutils literal">strftime()</tt>-compatible date/time format string. If empty, the
package substitutes ISO8601 format date/times, which is almost equivalent to
specifying the date format string <tt class="docutils literal">&quot;%Y-%m-%d %H:%M:%S&quot;</tt>. The ISO8601 format
also specifies milliseconds, which are appended to the result of using the above
format string, with a comma separator. An example time in ISO8601 format is
<tt class="docutils literal">2003-01-23 00:29:50,411</tt>.
The <tt class="docutils literal">class</tt> entry is optional. It indicates the name of the formatter&#8217;s class
(as a dotted module and class name.) This option is useful for instantiating a
<a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> subclass. Subclasses of <a title="logging.Formatter" class="reference internal" href="#logging.Formatter"><tt class="xref docutils literal">Formatter</tt></a> can present
exception tracebacks in an expanded or condensed format.
</div>
<div class="section" id="configuration-server-example">
<h3>15.6.20.3. Configuration server example<a class="headerlink" href="#configuration-server-example" title="Permalink to this headline">¶</a></h3>
Here is an example of a module using the logging configuration server:
<div class="highlight-python"><div class="highlight"><pre>import logging
import logging.config
import time
import os

# read initial config file
logging.config.fileConfig(&quot;logging.conf&quot;)

# create and start listener on port 9999
t = logging.config.listen(9999)
t.start()

try:
 # loop through logging calls to see the difference
 # new configurations make, until Ctrl+C is pressed
 while True:
 logger.debug(&quot;debug message&quot;)
 logger.info(&quot;info message&quot;)
 logger.warn(&quot;warn message&quot;)
 logger.error(&quot;error message&quot;)
 logger.critical(&quot;critical message&quot;)
 time.sleep(5)
except KeyboardInterrupt:
 # cleanup
 logging.config.stopListening()
 t.join()
</pre></div>
</div>
And here is a script that takes a filename and sends that file to the server,
properly preceded with the binary-encoded length, as the new logging
configuration:
<div class="highlight-python"><div class="highlight"><pre>#!/usr/bin/env python
import socket, sys, struct

data_to_send = open(sys.argv[1], &quot;r&quot;).read()

HOST = &#39;localhost&#39;
PORT = 9999
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print &quot;connecting...&quot;
s.connect((HOST, PORT))
print &quot;sending config...&quot;
s.send(struct.pack(&quot;&gt;L&quot;, len(data_to_send)))
s.send(data_to_send)
s.close()
print &quot;complete&quot;
</pre></div>
</div>
</div>
</div>
<div class="section" id="more-examples">
<h2>15.6.21. More examples<a class="headerlink" href="#more-examples" title="Permalink to this headline">¶</a></h2>
<div class="section" id="multiple-handlers-and-formatters">
<h3>15.6.21.1. Multiple handlers and formatters<a class="headerlink" href="#multiple-handlers-and-formatters" title="Permalink to this headline">¶</a></h3>
Loggers are plain Python objects. The <tt class="xref docutils literal">addHandler()</tt> method has no minimum
or maximum quota for the number of handlers you may add. Sometimes it will be
beneficial for an application to log all messages of all severities to a text
file while simultaneously logging errors or above to the console. To set this
up, simply configure the appropriate handlers. The logging calls in the
application code will remain unchanged. Here is a slight modification to the
previous simple module-based configuration example:
<div class="highlight-python"><div class="highlight"><pre>import logging

logger = logging.getLogger(&quot;simple_example&quot;)
logger.setLevel(logging.DEBUG)
# create file handler which logs even debug messages
fh = logging.FileHandler(&quot;spam.log&quot;)
fh.setLevel(logging.DEBUG)
# create console handler with a higher log level
ch = logging.StreamHandler()
ch.setLevel(logging.ERROR)
# create formatter and add it to the handlers
formatter = logging.Formatter(&quot;%(asctime)s - %(name)s - %(levelname)s - %(message)s&quot;)
ch.setFormatter(formatter)
fh.setFormatter(formatter)
# add the handlers to logger
logger.addHandler(ch)
logger.addHandler(fh)

# &quot;application&quot; code
logger.debug(&quot;debug message&quot;)
logger.info(&quot;info message&quot;)
logger.warn(&quot;warn message&quot;)
logger.error(&quot;error message&quot;)
logger.critical(&quot;critical message&quot;)
</pre></div>
</div>
Notice that the &#8220;application&#8221; code does not care about multiple handlers. All
that changed was the addition and configuration of a new handler named fh.
The ability to create new handlers with higher- or lower-severity filters can be
very helpful when writing and testing an application. Instead of using many
<tt class="docutils literal">print</tt> statements for debugging, use <tt class="docutils literal">logger.debug</tt>: Unlike the print
statements, which you will have to delete or comment out later, the logger.debug
statements can remain intact in the source code and remain dormant until you
need them again. At that time, the only change that needs to happen is to
modify the severity level of the logger and/or handler to debug.
</div>
<div class="section" id="using-logging-in-multiple-modules">
<h3>15.6.21.2. Using logging in multiple modules<a class="headerlink" href="#using-logging-in-multiple-modules" title="Permalink to this headline">¶</a></h3>
It was mentioned above that multiple calls to
<tt class="docutils literal">logging.getLogger('someLogger')</tt> return a reference to the same logger
object. This is true not only within the same module, but also across modules
as long as it is in the same Python interpreter process. It is true for
references to the same object; additionally, application code can define and
configure a parent logger in one module and create (but not configure) a child
logger in a separate module, and all logger calls to the child will pass up to
the parent. Here is a main module:
<div class="highlight-python"><div class="highlight"><pre>import logging
import auxiliary_module

# create logger with &quot;spam_application&quot;
logger = logging.getLogger(&quot;spam_application&quot;)
logger.setLevel(logging.DEBUG)
# create file handler which logs even debug messages
fh = logging.FileHandler(&quot;spam.log&quot;)
fh.setLevel(logging.DEBUG)
# create console handler with a higher log level
ch = logging.StreamHandler()
ch.setLevel(logging.ERROR)
# create formatter and add it to the handlers
formatter = logging.Formatter(&quot;%(asctime)s - %(name)s - %(levelname)s - %(message)s&quot;)
fh.setFormatter(formatter)
ch.setFormatter(formatter)
# add the handlers to the logger
logger.addHandler(fh)
logger.addHandler(ch)

logger.info(&quot;creating an instance of auxiliary_module.Auxiliary&quot;)
a = auxiliary_module.Auxiliary()
logger.info(&quot;created an instance of auxiliary_module.Auxiliary&quot;)
logger.info(&quot;calling auxiliary_module.Auxiliary.do_something&quot;)
a.do_something()
logger.info(&quot;finished auxiliary_module.Auxiliary.do_something&quot;)
logger.info(&quot;calling auxiliary_module.some_function()&quot;)
auxiliary_module.some_function()
logger.info(&quot;done with auxiliary_module.some_function()&quot;)
</pre></div>
</div>
Here is the auxiliary module:
<div class="highlight-python"><div class="highlight"><pre>import logging

# create logger
module_logger = logging.getLogger(&quot;spam_application.auxiliary&quot;)

class Auxiliary:
 def __init__(self):
 self.logger = logging.getLogger(&quot;spam_application.auxiliary.Auxiliary&quot;)
 self.logger.info(&quot;creating an instance of Auxiliary&quot;)
 def do_something(self):
 self.logger.info(&quot;doing something&quot;)
 a = 1 + 1
 self.logger.info(&quot;done doing something&quot;)

def some_function():
 module_logger.info(&quot;received a call to \&quot;some_function\&quot;&quot;)
</pre></div>
</div>
The output looks like this:
<div class="highlight-python"><pre>2005-03-23 23:47:11,663 - spam_application - INFO -
 creating an instance of auxiliary_module.Auxiliary
2005-03-23 23:47:11,665 - spam_application.auxiliary.Auxiliary - INFO -
 creating an instance of Auxiliary
2005-03-23 23:47:11,665 - spam_application - INFO -
 created an instance of auxiliary_module.Auxiliary
2005-03-23 23:47:11,668 - spam_application - INFO -
 calling auxiliary_module.Auxiliary.do_something
2005-03-23 23:47:11,668 - spam_application.auxiliary.Auxiliary - INFO -
 doing something
2005-03-23 23:47:11,669 - spam_application.auxiliary.Auxiliary - INFO -
 done doing something
2005-03-23 23:47:11,670 - spam_application - INFO -
 finished auxiliary_module.Auxiliary.do_something
2005-03-23 23:47:11,671 - spam_application - INFO -
 calling auxiliary_module.some_function()
2005-03-23 23:47:11,672 - spam_application.auxiliary - INFO -
 received a call to "some_function"
2005-03-23 23:47:11,673 - spam_application - INFO -
 done with auxiliary_module.some_function()</pre>
</div>
</div>
</div>
</div>

</div>
 </div>
 </div>
 <div class="sphinxsidebar">
 <div class="sphinxsidebarwrapper">
 <h3><a href="../contents.html">Table Of Contents</a></h3>
 <ul>
<li><a class="reference external" href="#">15.6. <tt class="docutils literal">logging</tt> &#8212; Logging facility for Python</a><ul>
<li><a class="reference external" href="#logging-tutorial">15.6.1. Logging tutorial</a><ul>
<li><a class="reference external" href="#simple-examples">15.6.1.1. Simple examples</a></li>
<li><a class="reference external" href="#loggers">15.6.1.2. Loggers</a></li>
<li><a class="reference external" href="#handlers">15.6.1.3. Handlers</a></li>
<li><a class="reference external" href="#formatters">15.6.1.4. Formatters</a></li>
<li><a class="reference external" href="#configuring-logging">15.6.1.5. Configuring Logging</a></li>
<li><a class="reference external" href="#configuring-logging-for-a-library">15.6.1.6. Configuring Logging for a Library</a></li>
</ul>
</li>
<li><a class="reference external" href="#logging-levels">15.6.2. Logging Levels</a></li>
<li><a class="reference external" href="#useful-handlers">15.6.3. Useful Handlers</a></li>
<li><a class="reference external" href="#module-level-functions">15.6.4. Module-Level Functions</a></li>
<li><a class="reference external" href="#logger-objects">15.6.5. Logger Objects</a></li>
<li><a class="reference external" href="#basic-example">15.6.6. Basic example</a></li>
<li><a class="reference external" href="#logging-to-multiple-destinations">15.6.7. Logging to multiple destinations</a></li>
<li><a class="reference external" href="#exceptions-raised-during-logging">15.6.8. Exceptions raised during logging</a></li>
<li><a class="reference external" href="#adding-contextual-information-to-your-logging-output">15.6.9. Adding contextual information to your logging output</a></li>
<li><a class="reference external" href="#logging-to-a-single-file-from-multiple-processes">15.6.10. Logging to a single file from multiple processes</a></li>
<li><a class="reference external" href="#sending-and-receiving-logging-events-across-a-network">15.6.11. Sending and receiving logging events across a network</a></li>
<li><a class="reference external" href="#using-arbitrary-objects-as-messages">15.6.12. Using arbitrary objects as messages</a></li>
<li><a class="reference external" href="#optimization">15.6.13. Optimization</a></li>
<li><a class="reference external" href="#handler-objects">15.6.14. Handler Objects</a><ul>
<li><a class="reference external" href="#streamhandler">15.6.14.1. StreamHandler</a></li>
<li><a class="reference external" href="#filehandler">15.6.14.2. FileHandler</a></li>
<li><a class="reference external" href="#watchedfilehandler">15.6.14.3. WatchedFileHandler</a></li>
<li><a class="reference external" href="#rotatingfilehandler">15.6.14.4. RotatingFileHandler</a></li>
<li><a class="reference external" href="#timedrotatingfilehandler">15.6.14.5. TimedRotatingFileHandler</a></li>
<li><a class="reference external" href="#sockethandler">15.6.14.6. SocketHandler</a></li>
<li><a class="reference external" href="#datagramhandler">15.6.14.7. DatagramHandler</a></li>
<li><a class="reference external" href="#sysloghandler">15.6.14.8. SysLogHandler</a></li>
<li><a class="reference external" href="#nteventloghandler">15.6.14.9. NTEventLogHandler</a></li>
<li><a class="reference external" href="#smtphandler">15.6.14.10. SMTPHandler</a></li>
<li><a class="reference external" href="#memoryhandler">15.6.14.11. MemoryHandler</a></li>
<li><a class="reference external" href="#httphandler">15.6.14.12. HTTPHandler</a></li>
</ul>
</li>
<li><a class="reference external" href="#formatter-objects">15.6.15. Formatter Objects</a></li>
<li><a class="reference external" href="#filter-objects">15.6.16. Filter Objects</a></li>
<li><a class="reference external" href="#logrecord-objects">15.6.17. LogRecord Objects</a></li>
<li><a class="reference external" href="#loggeradapter-objects">15.6.18. LoggerAdapter Objects</a></li>
<li><a class="reference external" href="#thread-safety">15.6.19. Thread Safety</a></li>
<li><a class="reference external" href="#configuration">15.6.20. Configuration</a><ul>
<li><a class="reference external" href="#configuration-functions">15.6.20.1. Configuration functions</a></li>
<li><a class="reference external" href="#configuration-file-format">15.6.20.2. Configuration file format</a></li>
<li><a class="reference external" href="#configuration-server-example">15.6.20.3. Configuration server example</a></li>
</ul>
</li>
<li><a class="reference external" href="#more-examples">15.6.21. More examples</a><ul>
<li><a class="reference external" href="#multiple-handlers-and-formatters">15.6.21.1. Multiple handlers and formatters</a></li>
<li><a class="reference external" href="#using-logging-in-multiple-modules">15.6.21.2. Using logging in multiple modules</a></li>
</ul>
</li>
</ul>
</li>
</ul>

<h4>Previous topic</h4>
 <a href="getopt.html"
 title="previous chapter">15.5. <tt class="docutils literal docutils literal">getopt</tt> &#8212; Parser for command line options</a>
 <h4>Next topic</h4>
 <a href="getpass.html"
 title="next chapter">15.7. <tt class="docutils literal docutils literal docutils literal">getpass</tt> &#8212; Portable password input</a>
<h3>This Page</h3>
<ul class="this-page-menu">
 <li><a href="../bugs.html">Report a Bug</a></li>
 <li><a href="../_sources/library/logging.txt"
 rel="nofollow">Show Source</a></li>
</ul>

<div id="searchbox" style="display: none">
 <h3>Quick search</h3>
 <form class="search" action="../search.html" method="get">
 <input type="text" name="q" size="18" />
 <input type="submit" value="Go" />
 <input type="hidden" name="check_keywords" value="yes" />
 <input type="hidden" name="area" value="default" />
 </form>
 
 Enter search terms or a module, class or function name.
 
 </div>
 <script type="text/javascript">$('#searchbox').show(0);</script>
 </div>
 </div>
 <div class="clearer"></div>
 </div>
 <div class="related">
 <h3>Navigation</h3>
 <ul>
 <li class="right" style="margin-right: 10px">
 <a href="../genindex.html" title="General Index"
 >index</a></li>
 <li class="right" >
 <a href="../modindex.html" title="Global Module Index"
 >modules</a> |</li>
 <li class="right" >
 <a href="getpass.html" title="15.7. getpass — Portable password input"
 >next</a> |</li>
 <li class="right" >
 <a href="getopt.html" title="15.5. getopt — Parser for command line options"
 >previous</a> |</li>
 <li><img src="../_static/py.png" alt=""
 style="vertical-align: middle; margin-top: -1px"/></li>
 <li><a href="../index.html">Python v2.6.6 documentation</a> &raquo;</li>

<li><a href="index.html" >The Python Standard Library</a> &raquo;</li>
 <li><a href="allos.html" >15. Generic Operating System Services</a> &raquo;</li> 
 </ul>
 </div>
 <div class="footer">
 &copy; <a href="../copyright.html">Copyright</a> 1990-2011, Python Software Foundation.
 
 The Python Software Foundation is a non-profit corporation. 
 <a href="http://www.python.org/psf/donations/">Please donate.</a>
 
 Last updated on Jul 20, 2011.
 <a href="../bugs.html">Found a bug</a>?
 
 Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 0.6.6.
 </div>

</body>
</html>

Back to File Manager