diff options
| author | Craig Jennings <c@cjennings.net> | 2024-04-07 13:41:34 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2024-04-07 13:41:34 -0500 |
| commit | 754bbf7a25a8dda49b5d08ef0d0443bbf5af0e36 (patch) | |
| tree | f1190704f78f04a2b0b4c977d20fe96a828377f1 /devdocs/python~3.12/library%2Flogging.handlers.html | |
new repository
Diffstat (limited to 'devdocs/python~3.12/library%2Flogging.handlers.html')
| -rw-r--r-- | devdocs/python~3.12/library%2Flogging.handlers.html | 297 |
1 files changed, 297 insertions, 0 deletions
diff --git a/devdocs/python~3.12/library%2Flogging.handlers.html b/devdocs/python~3.12/library%2Flogging.handlers.html new file mode 100644 index 00000000..6696ebf2 --- /dev/null +++ b/devdocs/python~3.12/library%2Flogging.handlers.html @@ -0,0 +1,297 @@ + <span id="logging-handlers-logging-handlers"></span><h1>logging.handlers — Logging handlers</h1> <p><strong>Source code:</strong> <a class="reference external" href="https://github.com/python/cpython/tree/3.12/Lib/logging/handlers.py">Lib/logging/handlers.py</a></p> <aside class="sidebar"> <p class="sidebar-title">Important</p> <p>This page contains only reference information. For tutorials, please see</p> <ul class="simple"> <li><a class="reference internal" href="../howto/logging#logging-basic-tutorial"><span class="std std-ref">Basic Tutorial</span></a></li> <li><a class="reference internal" href="../howto/logging#logging-advanced-tutorial"><span class="std std-ref">Advanced Tutorial</span></a></li> <li><a class="reference internal" href="../howto/logging-cookbook#logging-cookbook"><span class="std std-ref">Logging Cookbook</span></a></li> </ul> </aside> <p>The following useful handlers are provided in the package. Note that three of the handlers (<a class="reference internal" href="#logging.StreamHandler" title="logging.StreamHandler"><code>StreamHandler</code></a>, <a class="reference internal" href="#logging.FileHandler" title="logging.FileHandler"><code>FileHandler</code></a> and <a class="reference internal" href="#logging.NullHandler" title="logging.NullHandler"><code>NullHandler</code></a>) are actually defined in the <a class="reference internal" href="logging#module-logging" title="logging: Flexible event logging system for applications."><code>logging</code></a> module itself, but have been documented here along with the other handlers.</p> <section id="streamhandler"> <span id="stream-handler"></span><h2>StreamHandler</h2> <p>The <a class="reference internal" href="#logging.StreamHandler" title="logging.StreamHandler"><code>StreamHandler</code></a> class, located in the core <a class="reference internal" href="logging#module-logging" title="logging: Flexible event logging system for applications."><code>logging</code></a> package, sends logging output to streams such as <em>sys.stdout</em>, <em>sys.stderr</em> or any file-like object (or, more precisely, any object which supports <code>write()</code> and <code>flush()</code> methods).</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.StreamHandler"> +<code>class logging.StreamHandler(stream=None)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.StreamHandler" title="logging.StreamHandler"><code>StreamHandler</code></a> class. If <em>stream</em> is specified, the instance will use it for logging output; otherwise, <em>sys.stderr</em> will be used.</p> <dl class="py method"> <dt class="sig sig-object py" id="logging.StreamHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>If a formatter is specified, it is used to format the record. The record is then written to the stream followed by <a class="reference internal" href="#logging.StreamHandler.terminator" title="logging.StreamHandler.terminator"><code>terminator</code></a>. If exception information is present, it is formatted using <a class="reference internal" href="traceback#traceback.print_exception" title="traceback.print_exception"><code>traceback.print_exception()</code></a> and appended to the stream.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.StreamHandler.flush"> +<code>flush()</code> </dt> <dd> +<p>Flushes the stream by calling its <a class="reference internal" href="#logging.StreamHandler.flush" title="logging.StreamHandler.flush"><code>flush()</code></a> method. Note that the <code>close()</code> method is inherited from <a class="reference internal" href="logging#logging.Handler" title="logging.Handler"><code>Handler</code></a> and so does no output, so an explicit <a class="reference internal" href="#logging.StreamHandler.flush" title="logging.StreamHandler.flush"><code>flush()</code></a> call may be needed at times.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.StreamHandler.setStream"> +<code>setStream(stream)</code> </dt> <dd> +<p>Sets the instance’s stream to the specified value, if it is different. The old stream is flushed before the new stream is set.</p> <dl class="field-list simple"> <dt class="field-odd">Parameters</dt> <dd class="field-odd"> +<p><strong>stream</strong> – The stream that the handler should use.</p> </dd> <dt class="field-even">Returns</dt> <dd class="field-even"> +<p>the old stream, if the stream was changed, or <em>None</em> if it wasn’t.</p> </dd> </dl> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.7.</span></p> </div> </dd> +</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="logging.StreamHandler.terminator"> +<code>terminator</code> </dt> <dd> +<p>String used as the terminator when writing a formatted record to a stream. Default value is <code>'\n'</code>.</p> <p>If you don’t want a newline termination, you can set the handler instance’s <code>terminator</code> attribute to the empty string.</p> <p>In earlier versions, the terminator was hardcoded as <code>'\n'</code>.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.2.</span></p> </div> </dd> +</dl> </dd> +</dl> </section> <section id="filehandler"> <span id="file-handler"></span><h2>FileHandler</h2> <p>The <a class="reference internal" href="#logging.FileHandler" title="logging.FileHandler"><code>FileHandler</code></a> class, located in the core <a class="reference internal" href="logging#module-logging" title="logging: Flexible event logging system for applications."><code>logging</code></a> package, sends logging output to a disk file. It inherits the output functionality from <a class="reference internal" href="#logging.StreamHandler" title="logging.StreamHandler"><code>StreamHandler</code></a>.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.FileHandler"> +<code>class logging.FileHandler(filename, mode='a', encoding=None, delay=False, errors=None)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.FileHandler" title="logging.FileHandler"><code>FileHandler</code></a> class. The specified file is opened and used as the stream for logging. If <em>mode</em> is not specified, <code>'a'</code> is used. If <em>encoding</em> is not <code>None</code>, it is used to open the file with that encoding. If <em>delay</em> is true, then file opening is deferred until the first call to <a class="reference internal" href="#logging.FileHandler.emit" title="logging.FileHandler.emit"><code>emit()</code></a>. By default, the file grows indefinitely. If <em>errors</em> is specified, it’s used to determine how encoding errors are handled.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.6: </span>As well as string values, <a class="reference internal" href="pathlib#pathlib.Path" title="pathlib.Path"><code>Path</code></a> objects are also accepted for the <em>filename</em> argument.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.9: </span>The <em>errors</em> parameter was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.FileHandler.close"> +<code>close()</code> </dt> <dd> +<p>Closes the file.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.FileHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Outputs the record to the file.</p> <p>Note that if the file was closed due to logging shutdown at exit and the file mode is ‘w’, the record will not be emitted (see <a class="reference external" href="https://bugs.python.org/issue?@action=redirect&bpo=42378">bpo-42378</a>).</p> </dd> +</dl> </dd> +</dl> </section> <section id="nullhandler"> <span id="null-handler"></span><h2>NullHandler</h2> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.1.</span></p> </div> <p>The <a class="reference internal" href="#logging.NullHandler" title="logging.NullHandler"><code>NullHandler</code></a> class, located in the core <a class="reference internal" href="logging#module-logging" title="logging: Flexible event logging system for applications."><code>logging</code></a> package, does not do any formatting or output. It is essentially a ‘no-op’ handler for use by library developers.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.NullHandler"> +<code>class logging.NullHandler</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.NullHandler" title="logging.NullHandler"><code>NullHandler</code></a> class.</p> <dl class="py method"> <dt class="sig sig-object py" id="logging.NullHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>This method does nothing.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.NullHandler.handle"> +<code>handle(record)</code> </dt> <dd> +<p>This method does nothing.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.NullHandler.createLock"> +<code>createLock()</code> </dt> <dd> +<p>This method returns <code>None</code> for the lock, since there is no underlying I/O to which access needs to be serialized.</p> </dd> +</dl> </dd> +</dl> <p>See <a class="reference internal" href="../howto/logging#library-config"><span class="std std-ref">Configuring Logging for a Library</span></a> for more information on how to use <a class="reference internal" href="#logging.NullHandler" title="logging.NullHandler"><code>NullHandler</code></a>.</p> </section> <section id="watchedfilehandler"> <span id="watched-file-handler"></span><h2>WatchedFileHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.WatchedFileHandler" title="logging.handlers.WatchedFileHandler"><code>WatchedFileHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, is a <code>FileHandler</code> which watches the file it is logging to. If the file changes, it is closed and reopened using the file name.</p> <p>A file change can happen because of usage of programs such as <em>newsyslog</em> and <em>logrotate</em> 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.</p> <p>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, <em>ST_INO</em> is not supported under Windows; <a class="reference internal" href="os#os.stat" title="os.stat"><code>stat()</code></a> always returns zero for this value.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.WatchedFileHandler"> +<code>class logging.handlers.WatchedFileHandler(filename, mode='a', encoding=None, delay=False, errors=None)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.WatchedFileHandler" title="logging.handlers.WatchedFileHandler"><code>WatchedFileHandler</code></a> class. The specified file is opened and used as the stream for logging. If <em>mode</em> is not specified, <code>'a'</code> is used. If <em>encoding</em> is not <code>None</code>, it is used to open the file with that encoding. If <em>delay</em> is true, then file opening is deferred until the first call to <a class="reference internal" href="#logging.handlers.WatchedFileHandler.emit" title="logging.handlers.WatchedFileHandler.emit"><code>emit()</code></a>. By default, the file grows indefinitely. If <em>errors</em> is provided, it determines how encoding errors are handled.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.6: </span>As well as string values, <a class="reference internal" href="pathlib#pathlib.Path" title="pathlib.Path"><code>Path</code></a> objects are also accepted for the <em>filename</em> argument.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.9: </span>The <em>errors</em> parameter was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.WatchedFileHandler.reopenIfNeeded"> +<code>reopenIfNeeded()</code> </dt> <dd> +<p>Checks to see if the file has changed. If it has, the existing stream is flushed and closed and the file opened again, typically as a precursor to outputting the record to the file.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.6.</span></p> </div> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.WatchedFileHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Outputs the record to the file, but first calls <a class="reference internal" href="#logging.handlers.WatchedFileHandler.reopenIfNeeded" title="logging.handlers.WatchedFileHandler.reopenIfNeeded"><code>reopenIfNeeded()</code></a> to reopen the file if it has changed.</p> </dd> +</dl> </dd> +</dl> </section> <section id="baserotatinghandler"> <span id="base-rotating-handler"></span><h2>BaseRotatingHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.BaseRotatingHandler" title="logging.handlers.BaseRotatingHandler"><code>BaseRotatingHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, is the base class for the rotating file handlers, <a class="reference internal" href="#logging.handlers.RotatingFileHandler" title="logging.handlers.RotatingFileHandler"><code>RotatingFileHandler</code></a> and <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler" title="logging.handlers.TimedRotatingFileHandler"><code>TimedRotatingFileHandler</code></a>. You should not need to instantiate this class, but it has attributes and methods you may need to override.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.BaseRotatingHandler"> +<code>class logging.handlers.BaseRotatingHandler(filename, mode, encoding=None, delay=False, errors=None)</code> </dt> <dd> +<p>The parameters are as for <code>FileHandler</code>. The attributes are:</p> <dl class="py attribute"> <dt class="sig sig-object py" id="logging.handlers.BaseRotatingHandler.namer"> +<code>namer</code> </dt> <dd> +<p>If this attribute is set to a callable, the <a class="reference internal" href="#logging.handlers.BaseRotatingHandler.rotation_filename" title="logging.handlers.BaseRotatingHandler.rotation_filename"><code>rotation_filename()</code></a> method delegates to this callable. The parameters passed to the callable are those passed to <a class="reference internal" href="#logging.handlers.BaseRotatingHandler.rotation_filename" title="logging.handlers.BaseRotatingHandler.rotation_filename"><code>rotation_filename()</code></a>.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>The namer function is called quite a few times during rollover, so it should be as simple and as fast as possible. It should also return the same output every time for a given input, otherwise the rollover behaviour may not work as expected.</p> <p>It’s also worth noting that care should be taken when using a namer to preserve certain attributes in the filename which are used during rotation. For example, <a class="reference internal" href="#logging.handlers.RotatingFileHandler" title="logging.handlers.RotatingFileHandler"><code>RotatingFileHandler</code></a> expects to have a set of log files whose names contain successive integers, so that rotation works as expected, and <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler" title="logging.handlers.TimedRotatingFileHandler"><code>TimedRotatingFileHandler</code></a> deletes old log files (based on the <code>backupCount</code> parameter passed to the handler’s initializer) by determining the oldest files to delete. For this to happen, the filenames should be sortable using the date/time portion of the filename, and a namer needs to respect this. (If a namer is wanted that doesn’t respect this scheme, it will need to be used in a subclass of <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler" title="logging.handlers.TimedRotatingFileHandler"><code>TimedRotatingFileHandler</code></a> which overrides the <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler.getFilesToDelete" title="logging.handlers.TimedRotatingFileHandler.getFilesToDelete"><code>getFilesToDelete()</code></a> method to fit in with the custom naming scheme.)</p> </div> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.3.</span></p> </div> </dd> +</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="logging.handlers.BaseRotatingHandler.rotator"> +<code>rotator</code> </dt> <dd> +<p>If this attribute is set to a callable, the <a class="reference internal" href="#logging.handlers.BaseRotatingHandler.rotate" title="logging.handlers.BaseRotatingHandler.rotate"><code>rotate()</code></a> method delegates to this callable. The parameters passed to the callable are those passed to <a class="reference internal" href="#logging.handlers.BaseRotatingHandler.rotate" title="logging.handlers.BaseRotatingHandler.rotate"><code>rotate()</code></a>.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.3.</span></p> </div> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.BaseRotatingHandler.rotation_filename"> +<code>rotation_filename(default_name)</code> </dt> <dd> +<p>Modify the filename of a log file when rotating.</p> <p>This is provided so that a custom filename can be provided.</p> <p>The default implementation calls the ‘namer’ attribute of the handler, if it’s callable, passing the default name to it. If the attribute isn’t callable (the default is <code>None</code>), the name is returned unchanged.</p> <dl class="field-list simple"> <dt class="field-odd">Parameters</dt> <dd class="field-odd"> +<p><strong>default_name</strong> – The default name for the log file.</p> </dd> </dl> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.3.</span></p> </div> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.BaseRotatingHandler.rotate"> +<code>rotate(source, dest)</code> </dt> <dd> +<p>When rotating, rotate the current log.</p> <p>The default implementation calls the ‘rotator’ attribute of the handler, if it’s callable, passing the source and dest arguments to it. If the attribute isn’t callable (the default is <code>None</code>), the source is simply renamed to the destination.</p> <dl class="field-list simple"> <dt class="field-odd">Parameters</dt> <dd class="field-odd"> +<ul class="simple"> <li> +<strong>source</strong> – The source filename. This is normally the base filename, e.g. ‘test.log’.</li> <li> +<strong>dest</strong> – The destination filename. This is normally what the source is rotated to, e.g. ‘test.log.1’.</li> </ul> </dd> </dl> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.3.</span></p> </div> </dd> +</dl> </dd> +</dl> <p>The reason the attributes exist is to save you having to subclass - you can use the same callables for instances of <a class="reference internal" href="#logging.handlers.RotatingFileHandler" title="logging.handlers.RotatingFileHandler"><code>RotatingFileHandler</code></a> and <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler" title="logging.handlers.TimedRotatingFileHandler"><code>TimedRotatingFileHandler</code></a>. If either the namer or rotator callable raises an exception, this will be handled in the same way as any other exception during an <code>emit()</code> call, i.e. via the <code>handleError()</code> method of the handler.</p> <p>If you need to make more significant changes to rotation processing, you can override the methods.</p> <p>For an example, see <a class="reference internal" href="../howto/logging-cookbook#cookbook-rotator-namer"><span class="std std-ref">Using a rotator and namer to customize log rotation processing</span></a>.</p> </section> <section id="rotatingfilehandler"> <span id="rotating-file-handler"></span><h2>RotatingFileHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.RotatingFileHandler" title="logging.handlers.RotatingFileHandler"><code>RotatingFileHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports rotation of disk log files.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.RotatingFileHandler"> +<code>class logging.handlers.RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=False, errors=None)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.RotatingFileHandler" title="logging.handlers.RotatingFileHandler"><code>RotatingFileHandler</code></a> class. The specified file is opened and used as the stream for logging. If <em>mode</em> is not specified, <code>'a'</code> is used. If <em>encoding</em> is not <code>None</code>, it is used to open the file with that encoding. If <em>delay</em> is true, then file opening is deferred until the first call to <a class="reference internal" href="#logging.handlers.RotatingFileHandler.emit" title="logging.handlers.RotatingFileHandler.emit"><code>emit()</code></a>. By default, the file grows indefinitely. If <em>errors</em> is provided, it determines how encoding errors are handled.</p> <p>You can use the <em>maxBytes</em> and <em>backupCount</em> values to allow the file to <em class="dfn">rollover</em> 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 <em>maxBytes</em> in length; but if either of <em>maxBytes</em> or <em>backupCount</em> is zero, rollover never occurs, so you generally want to set <em>backupCount</em> to at least 1, and have a non-zero <em>maxBytes</em>. When <em>backupCount</em> is non-zero, the system will save old log files by appending the extensions ‘.1’, ‘.2’ etc., to the filename. For example, with a <em>backupCount</em> of 5 and a base file name of <code>app.log</code>, you would get <code>app.log</code>, <code>app.log.1</code>, <code>app.log.2</code>, up to <code>app.log.5</code>. The file being written to is always <code>app.log</code>. When this file is filled, it is closed and renamed to <code>app.log.1</code>, and if files <code>app.log.1</code>, <code>app.log.2</code>, etc. exist, then they are renamed to <code>app.log.2</code>, <code>app.log.3</code> etc. respectively.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.6: </span>As well as string values, <a class="reference internal" href="pathlib#pathlib.Path" title="pathlib.Path"><code>Path</code></a> objects are also accepted for the <em>filename</em> argument.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.9: </span>The <em>errors</em> parameter was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.RotatingFileHandler.doRollover"> +<code>doRollover()</code> </dt> <dd> +<p>Does a rollover, as described above.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.RotatingFileHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Outputs the record to the file, catering for rollover as described previously.</p> </dd> +</dl> </dd> +</dl> </section> <section id="timedrotatingfilehandler"> <span id="timed-rotating-file-handler"></span><h2>TimedRotatingFileHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler" title="logging.handlers.TimedRotatingFileHandler"><code>TimedRotatingFileHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports rotation of disk log files at certain timed intervals.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.TimedRotatingFileHandler"> +<code>class logging.handlers.TimedRotatingFileHandler(filename, when='h', interval=1, backupCount=0, encoding=None, delay=False, utc=False, atTime=None, errors=None)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler" title="logging.handlers.TimedRotatingFileHandler"><code>TimedRotatingFileHandler</code></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 <em>when</em> and <em>interval</em>.</p> <p>You can use the <em>when</em> to specify the type of <em>interval</em>. The list of possible values is below. Note that they are not case sensitive.</p> <table class="docutils align-default"> <thead> <tr> +<th class="head"><p>Value</p></th> <th class="head"><p>Type of interval</p></th> <th class="head"><p>If/how <em>atTime</em> is used</p></th> </tr> </thead> <tr> +<td><p><code>'S'</code></p></td> <td><p>Seconds</p></td> <td><p>Ignored</p></td> </tr> <tr> +<td><p><code>'M'</code></p></td> <td><p>Minutes</p></td> <td><p>Ignored</p></td> </tr> <tr> +<td><p><code>'H'</code></p></td> <td><p>Hours</p></td> <td><p>Ignored</p></td> </tr> <tr> +<td><p><code>'D'</code></p></td> <td><p>Days</p></td> <td><p>Ignored</p></td> </tr> <tr> +<td><p><code>'W0'-'W6'</code></p></td> <td><p>Weekday (0=Monday)</p></td> <td><p>Used to compute initial rollover time</p></td> </tr> <tr> +<td><p><code>'midnight'</code></p></td> <td><p>Roll over at midnight, if <em>atTime</em> not specified, else at time <em>atTime</em></p></td> <td><p>Used to compute initial rollover time</p></td> </tr> </table> <p>When using weekday-based rotation, specify ‘W0’ for Monday, ‘W1’ for Tuesday, and so on up to ‘W6’ for Sunday. In this case, the value passed for <em>interval</em> isn’t used.</p> <p>The system will save old log files by appending extensions to the filename. The extensions are date-and-time based, using the strftime format <code>%Y-%m-%d_%H-%M-%S</code> or a leading portion thereof, depending on the rollover interval.</p> <p>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.</p> <p>If the <em>utc</em> argument is true, times in UTC will be used; otherwise local time is used.</p> <p>If <em>backupCount</em> is nonzero, at most <em>backupCount</em> 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.</p> <p>If <em>delay</em> is true, then file opening is deferred until the first call to <a class="reference internal" href="#logging.handlers.TimedRotatingFileHandler.emit" title="logging.handlers.TimedRotatingFileHandler.emit"><code>emit()</code></a>.</p> <p>If <em>atTime</em> is not <code>None</code>, it must be a <code>datetime.time</code> instance which specifies the time of day when rollover occurs, for the cases where rollover is set to happen “at midnight” or “on a particular weekday”. Note that in these cases, the <em>atTime</em> value is effectively used to compute the <em>initial</em> rollover, and subsequent rollovers would be calculated via the normal interval calculation.</p> <p>If <em>errors</em> is specified, it’s used to determine how encoding errors are handled.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>Calculation of the initial rollover time is done when the handler is initialised. Calculation of subsequent rollover times is done only when rollover occurs, and rollover occurs only when emitting output. If this is not kept in mind, it might lead to some confusion. For example, if an interval of “every minute” is set, that does not mean you will always see log files with times (in the filename) separated by a minute; if, during application execution, logging output is generated more frequently than once a minute, <em>then</em> you can expect to see log files with times separated by a minute. If, on the other hand, logging messages are only output once every five minutes (say), then there will be gaps in the file times corresponding to the minutes where no output (and hence no rollover) occurred.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.4: </span><em>atTime</em> parameter was added.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.6: </span>As well as string values, <a class="reference internal" href="pathlib#pathlib.Path" title="pathlib.Path"><code>Path</code></a> objects are also accepted for the <em>filename</em> argument.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.9: </span>The <em>errors</em> parameter was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.TimedRotatingFileHandler.doRollover"> +<code>doRollover()</code> </dt> <dd> +<p>Does a rollover, as described above.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.TimedRotatingFileHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Outputs the record to the file, catering for rollover as described above.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.TimedRotatingFileHandler.getFilesToDelete"> +<code>getFilesToDelete()</code> </dt> <dd> +<p>Returns a list of filenames which should be deleted as part of rollover. These are the absolute paths of the oldest backup log files written by the handler.</p> </dd> +</dl> </dd> +</dl> </section> <section id="sockethandler"> <span id="socket-handler"></span><h2>SocketHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.SocketHandler" title="logging.handlers.SocketHandler"><code>SocketHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, sends logging output to a network socket. The base class uses a TCP socket.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler"> +<code>class logging.handlers.SocketHandler(host, port)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.SocketHandler" title="logging.handlers.SocketHandler"><code>SocketHandler</code></a> class intended to communicate with a remote machine whose address is given by <em>host</em> and <em>port</em>.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.4: </span>If <code>port</code> is specified as <code>None</code>, a Unix domain socket is created using the value in <code>host</code> - otherwise, a TCP socket is created.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler.close"> +<code>close()</code> </dt> <dd> +<p>Closes the socket.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler.emit"> +<code>emit()</code> </dt> <dd> +<p>Pickles the record’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 class="reference internal" href="logging#logging.LogRecord" title="logging.LogRecord"><code>LogRecord</code></a>, use the <a class="reference internal" href="logging#logging.makeLogRecord" title="logging.makeLogRecord"><code>makeLogRecord()</code></a> function.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler.handleError"> +<code>handleError()</code> </dt> <dd> +<p>Handles an error which has occurred during <a class="reference internal" href="#logging.handlers.SocketHandler.emit" title="logging.handlers.SocketHandler.emit"><code>emit()</code></a>. The most likely cause is a lost connection. Closes the socket so that we can retry on the next event.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler.makeSocket"> +<code>makeSocket()</code> </dt> <dd> +<p>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 class="reference internal" href="socket#socket.SOCK_STREAM" title="socket.SOCK_STREAM"><code>socket.SOCK_STREAM</code></a>).</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler.makePickle"> +<code>makePickle(record)</code> </dt> <dd> +<p>Pickles the record’s attribute dictionary in binary format with a length prefix, and returns it ready for transmission across the socket. The details of this operation are equivalent to:</p> <pre data-language="python">data = pickle.dumps(record_attr_dict, 1) +datalen = struct.pack('>L', len(data)) +return datalen + data +</pre> <p>Note that pickles aren’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.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler.send"> +<code>send(packet)</code> </dt> <dd> +<p>Send a pickled byte-string <em>packet</em> to the socket. The format of the sent byte-string is as described in the documentation for <a class="reference internal" href="#logging.handlers.SocketHandler.makePickle" title="logging.handlers.SocketHandler.makePickle"><code>makePickle()</code></a>.</p> <p>This function allows for partial sends, which can happen when the network is busy.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SocketHandler.createSocket"> +<code>createSocket()</code> </dt> <dd> +<p>Tries to create a socket; on failure, uses an exponential back-off algorithm. On initial failure, the handler will drop the message it was trying to send. When subsequent messages are handled by the same instance, it will not try connecting until some time has passed. The default parameters are such that the initial delay is one second, and if after that delay the connection still can’t be made, the handler will double the delay each time up to a maximum of 30 seconds.</p> <p>This behaviour is controlled by the following handler attributes:</p> <ul class="simple"> <li> +<code>retryStart</code> (initial delay, defaulting to 1.0 seconds).</li> <li> +<code>retryFactor</code> (multiplier, defaulting to 2.0).</li> <li> +<code>retryMax</code> (maximum delay, defaulting to 30.0 seconds).</li> </ul> <p>This means that if the remote listener starts up <em>after</em> the handler has been used, you could lose messages (since the handler won’t even attempt a connection until the delay has elapsed, but just silently drop messages during the delay period).</p> </dd> +</dl> </dd> +</dl> </section> <section id="datagramhandler"> <span id="datagram-handler"></span><h2>DatagramHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.DatagramHandler" title="logging.handlers.DatagramHandler"><code>DatagramHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, inherits from <a class="reference internal" href="#logging.handlers.SocketHandler" title="logging.handlers.SocketHandler"><code>SocketHandler</code></a> to support sending logging messages over UDP sockets.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.DatagramHandler"> +<code>class logging.handlers.DatagramHandler(host, port)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.DatagramHandler" title="logging.handlers.DatagramHandler"><code>DatagramHandler</code></a> class intended to communicate with a remote machine whose address is given by <em>host</em> and <em>port</em>.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>As UDP is not a streaming protocol, there is no persistent connection between an instance of this handler and <em>host</em>. For this reason, when using a network socket, a DNS lookup might have to be made each time an event is logged, which can introduce some latency into the system. If this affects you, you can do a lookup yourself and initialize this handler using the looked-up IP address rather than the hostname.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.4: </span>If <code>port</code> is specified as <code>None</code>, a Unix domain socket is created using the value in <code>host</code> - otherwise, a UDP socket is created.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.DatagramHandler.emit"> +<code>emit()</code> </dt> <dd> +<p>Pickles the record’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 class="reference internal" href="logging#logging.LogRecord" title="logging.LogRecord"><code>LogRecord</code></a>, use the <a class="reference internal" href="logging#logging.makeLogRecord" title="logging.makeLogRecord"><code>makeLogRecord()</code></a> function.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.DatagramHandler.makeSocket"> +<code>makeSocket()</code> </dt> <dd> +<p>The factory method of <a class="reference internal" href="#logging.handlers.SocketHandler" title="logging.handlers.SocketHandler"><code>SocketHandler</code></a> is here overridden to create a UDP socket (<a class="reference internal" href="socket#socket.SOCK_DGRAM" title="socket.SOCK_DGRAM"><code>socket.SOCK_DGRAM</code></a>).</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.DatagramHandler.send"> +<code>send(s)</code> </dt> <dd> +<p>Send a pickled byte-string to a socket. The format of the sent byte-string is as described in the documentation for <a class="reference internal" href="#logging.handlers.SocketHandler.makePickle" title="logging.handlers.SocketHandler.makePickle"><code>SocketHandler.makePickle()</code></a>.</p> </dd> +</dl> </dd> +</dl> </section> <section id="sysloghandler"> <span id="syslog-handler"></span><h2>SysLogHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.SysLogHandler" title="logging.handlers.SysLogHandler"><code>SysLogHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports sending logging messages to a remote or local Unix syslog.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.SysLogHandler"> +<code>class logging.handlers.SysLogHandler(address=('localhost', SYSLOG_UDP_PORT), facility=LOG_USER, socktype=socket.SOCK_DGRAM)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.SysLogHandler" title="logging.handlers.SysLogHandler"><code>SysLogHandler</code></a> class intended to communicate with a remote Unix machine whose address is given by <em>address</em> in the form of a <code>(host, port)</code> tuple. If <em>address</em> is not specified, <code>('localhost', 514)</code> is used. The address is used to open a socket. An alternative to providing a <code>(host, port)</code> tuple is providing an address as a string, for example ‘/dev/log’. In this case, a Unix domain socket is used to send the message to the syslog. If <em>facility</em> is not specified, <code>LOG_USER</code> is used. The type of socket opened depends on the <em>socktype</em> argument, which defaults to <a class="reference internal" href="socket#socket.SOCK_DGRAM" title="socket.SOCK_DGRAM"><code>socket.SOCK_DGRAM</code></a> and thus opens a UDP socket. To open a TCP socket (for use with the newer syslog daemons such as rsyslog), specify a value of <a class="reference internal" href="socket#socket.SOCK_STREAM" title="socket.SOCK_STREAM"><code>socket.SOCK_STREAM</code></a>.</p> <p>Note that if your server is not listening on UDP port 514, <a class="reference internal" href="#logging.handlers.SysLogHandler" title="logging.handlers.SysLogHandler"><code>SysLogHandler</code></a> may appear not to work. In that case, check what address you should be using for a domain socket - it’s system dependent. For example, on Linux it’s usually ‘/dev/log’ but on OS/X it’s ‘/var/run/syslog’. You’ll need to check your platform and use the appropriate address (you may need to do this check at runtime if your application needs to run on several platforms). On Windows, you pretty much have to use the UDP option.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>On macOS 12.x (Monterey), Apple has changed the behaviour of their syslog daemon - it no longer listens on a domain socket. Therefore, you cannot expect <a class="reference internal" href="#logging.handlers.SysLogHandler" title="logging.handlers.SysLogHandler"><code>SysLogHandler</code></a> to work on this system.</p> <p>See <a class="reference external" href="https://github.com/python/cpython/issues/91070">gh-91070</a> for more information.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.2: </span><em>socktype</em> was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SysLogHandler.close"> +<code>close()</code> </dt> <dd> +<p>Closes the socket to the remote host.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SysLogHandler.createSocket"> +<code>createSocket()</code> </dt> <dd> +<p>Tries to create a socket and, if it’s not a datagram socket, connect it to the other end. This method is called during handler initialization, but it’s not regarded as an error if the other end isn’t listening at this point - the method will be called again when emitting an event, if there is no socket at that point.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.11.</span></p> </div> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SysLogHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>The record is formatted, and then sent to the syslog server. If exception information is present, it is <em>not</em> sent to the server.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.2.1: </span>(See: <a class="reference external" href="https://bugs.python.org/issue?@action=redirect&bpo=12168">bpo-12168</a>.) In earlier versions, the message sent to the syslog daemons was always terminated with a NUL byte, because early versions of these daemons expected a NUL terminated message - even though it’s not in the relevant specification (<span class="target" id="index-0"></span><a class="rfc reference external" href="https://datatracker.ietf.org/doc/html/rfc5424.html"><strong>RFC 5424</strong></a>). More recent versions of these daemons don’t expect the NUL byte but strip it off if it’s there, and even more recent daemons (which adhere more closely to RFC 5424) pass the NUL byte on as part of the message.</p> <p>To enable easier handling of syslog messages in the face of all these differing daemon behaviours, the appending of the NUL byte has been made configurable, through the use of a class-level attribute, <code>append_nul</code>. This defaults to <code>True</code> (preserving the existing behaviour) but can be set to <code>False</code> on a <code>SysLogHandler</code> instance in order for that instance to <em>not</em> append the NUL terminator.</p> </div> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.3: </span>(See: <a class="reference external" href="https://bugs.python.org/issue?@action=redirect&bpo=12419">bpo-12419</a>.) In earlier versions, there was no facility for an “ident” or “tag” prefix to identify the source of the message. This can now be specified using a class-level attribute, defaulting to <code>""</code> to preserve existing behaviour, but which can be overridden on a <code>SysLogHandler</code> instance in order for that instance to prepend the ident to every message handled. Note that the provided ident must be text, not bytes, and is prepended to the message exactly as is.</p> </div> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SysLogHandler.encodePriority"> +<code>encodePriority(facility, priority)</code> </dt> <dd> +<p>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.</p> <p>The symbolic <code>LOG_</code> values are defined in <a class="reference internal" href="#logging.handlers.SysLogHandler" title="logging.handlers.SysLogHandler"><code>SysLogHandler</code></a> and mirror the values defined in the <code>sys/syslog.h</code> header file.</p> <p><strong>Priorities</strong></p> <table class="docutils align-default"> <thead> <tr> +<th class="head"><p>Name (string)</p></th> <th class="head"><p>Symbolic value</p></th> </tr> </thead> <tr> +<td><p><code>alert</code></p></td> <td><p>LOG_ALERT</p></td> </tr> <tr> +<td><p><code>crit</code> or <code>critical</code></p></td> <td><p>LOG_CRIT</p></td> </tr> <tr> +<td><p><code>debug</code></p></td> <td><p>LOG_DEBUG</p></td> </tr> <tr> +<td><p><code>emerg</code> or <code>panic</code></p></td> <td><p>LOG_EMERG</p></td> </tr> <tr> +<td><p><code>err</code> or <code>error</code></p></td> <td><p>LOG_ERR</p></td> </tr> <tr> +<td><p><code>info</code></p></td> <td><p>LOG_INFO</p></td> </tr> <tr> +<td><p><code>notice</code></p></td> <td><p>LOG_NOTICE</p></td> </tr> <tr> +<td><p><code>warn</code> or <code>warning</code></p></td> <td><p>LOG_WARNING</p></td> </tr> </table> <p><strong>Facilities</strong></p> <table class="docutils align-default"> <thead> <tr> +<th class="head"><p>Name (string)</p></th> <th class="head"><p>Symbolic value</p></th> </tr> </thead> <tr> +<td><p><code>auth</code></p></td> <td><p>LOG_AUTH</p></td> </tr> <tr> +<td><p><code>authpriv</code></p></td> <td><p>LOG_AUTHPRIV</p></td> </tr> <tr> +<td><p><code>cron</code></p></td> <td><p>LOG_CRON</p></td> </tr> <tr> +<td><p><code>daemon</code></p></td> <td><p>LOG_DAEMON</p></td> </tr> <tr> +<td><p><code>ftp</code></p></td> <td><p>LOG_FTP</p></td> </tr> <tr> +<td><p><code>kern</code></p></td> <td><p>LOG_KERN</p></td> </tr> <tr> +<td><p><code>lpr</code></p></td> <td><p>LOG_LPR</p></td> </tr> <tr> +<td><p><code>mail</code></p></td> <td><p>LOG_MAIL</p></td> </tr> <tr> +<td><p><code>news</code></p></td> <td><p>LOG_NEWS</p></td> </tr> <tr> +<td><p><code>syslog</code></p></td> <td><p>LOG_SYSLOG</p></td> </tr> <tr> +<td><p><code>user</code></p></td> <td><p>LOG_USER</p></td> </tr> <tr> +<td><p><code>uucp</code></p></td> <td><p>LOG_UUCP</p></td> </tr> <tr> +<td><p><code>local0</code></p></td> <td><p>LOG_LOCAL0</p></td> </tr> <tr> +<td><p><code>local1</code></p></td> <td><p>LOG_LOCAL1</p></td> </tr> <tr> +<td><p><code>local2</code></p></td> <td><p>LOG_LOCAL2</p></td> </tr> <tr> +<td><p><code>local3</code></p></td> <td><p>LOG_LOCAL3</p></td> </tr> <tr> +<td><p><code>local4</code></p></td> <td><p>LOG_LOCAL4</p></td> </tr> <tr> +<td><p><code>local5</code></p></td> <td><p>LOG_LOCAL5</p></td> </tr> <tr> +<td><p><code>local6</code></p></td> <td><p>LOG_LOCAL6</p></td> </tr> <tr> +<td><p><code>local7</code></p></td> <td><p>LOG_LOCAL7</p></td> </tr> </table> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SysLogHandler.mapPriority"> +<code>mapPriority(levelname)</code> </dt> <dd> +<p>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 <code>DEBUG</code>, <code>INFO</code>, <code>WARNING</code>, <code>ERROR</code> and <code>CRITICAL</code> to the equivalent syslog names, and all other level names to ‘warning’.</p> </dd> +</dl> </dd> +</dl> </section> <section id="nteventloghandler"> <span id="nt-eventlog-handler"></span><h2>NTEventLogHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.NTEventLogHandler" title="logging.handlers.NTEventLogHandler"><code>NTEventLogHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> 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’s Win32 extensions for Python installed.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.NTEventLogHandler"> +<code>class logging.handlers.NTEventLogHandler(appname, dllname=None, logtype='Application')</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.NTEventLogHandler" title="logging.handlers.NTEventLogHandler"><code>NTEventLogHandler</code></a> class. The <em>appname</em> is used to define the application name as it appears in the event log. An appropriate registry entry is created using this name. The <em>dllname</em> should give the fully qualified pathname of a .dll or .exe which contains message definitions to hold in the log (if not specified, <code>'win32service.pyd'</code> 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 <em>logtype</em> is one of <code>'Application'</code>, <code>'System'</code> or <code>'Security'</code>, and defaults to <code>'Application'</code>.</p> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.NTEventLogHandler.close"> +<code>close()</code> </dt> <dd> +<p>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.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.NTEventLogHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Determines the message ID, event category and event type, and then logs the message in the NT event log.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.NTEventLogHandler.getEventCategory"> +<code>getEventCategory(record)</code> </dt> <dd> +<p>Returns the event category for the record. Override this if you want to specify your own categories. This version returns 0.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.NTEventLogHandler.getEventType"> +<code>getEventType(record)</code> </dt> <dd> +<p>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’s typemap attribute, which is set up in <code>__init__()</code> to a dictionary which contains mappings for <code>DEBUG</code>, <code>INFO</code>, <code>WARNING</code>, <code>ERROR</code> and <code>CRITICAL</code>. If you are using your own levels, you will either need to override this method or place a suitable dictionary in the handler’s <em>typemap</em> attribute.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.NTEventLogHandler.getMessageID"> +<code>getMessageID(record)</code> </dt> <dd> +<p>Returns the message ID for the record. If you are using your own messages, you could do this by having the <em>msg</em> 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 <code>win32service.pyd</code>.</p> </dd> +</dl> </dd> +</dl> </section> <section id="smtphandler"> <span id="smtp-handler"></span><h2>SMTPHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.SMTPHandler" title="logging.handlers.SMTPHandler"><code>SMTPHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports sending logging messages to an email address via SMTP.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.SMTPHandler"> +<code>class logging.handlers.SMTPHandler(mailhost, fromaddr, toaddrs, subject, credentials=None, secure=None, timeout=1.0)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.SMTPHandler" title="logging.handlers.SMTPHandler"><code>SMTPHandler</code></a> class. The instance is initialized with the from and to addresses and subject line of the email. The <em>toaddrs</em> should be a list of strings. To specify a non-standard SMTP port, use the (host, port) tuple format for the <em>mailhost</em> 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 <em>credentials</em> argument.</p> <p>To specify the use of a secure protocol (TLS), pass in a tuple to the <em>secure</em> argument. This will only be used when authentication credentials are supplied. The tuple should be either an empty tuple, or a single-value tuple with the name of a keyfile, or a 2-value tuple with the names of the keyfile and certificate file. (This tuple is passed to the <a class="reference internal" href="smtplib#smtplib.SMTP.starttls" title="smtplib.SMTP.starttls"><code>smtplib.SMTP.starttls()</code></a> method.)</p> <p>A timeout can be specified for communication with the SMTP server using the <em>timeout</em> argument.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.3: </span>The <em>timeout</em> argument was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SMTPHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Formats the record and sends it to the specified addressees.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.SMTPHandler.getSubject"> +<code>getSubject(record)</code> </dt> <dd> +<p>If you want to specify a subject line which is record-dependent, override this method.</p> </dd> +</dl> </dd> +</dl> </section> <section id="memoryhandler"> <span id="memory-handler"></span><h2>MemoryHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.MemoryHandler" title="logging.handlers.MemoryHandler"><code>MemoryHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports buffering of logging records in memory, periodically flushing them to a <em class="dfn">target</em> handler. Flushing occurs whenever the buffer is full, or when an event of a certain severity or greater is seen.</p> <p><a class="reference internal" href="#logging.handlers.MemoryHandler" title="logging.handlers.MemoryHandler"><code>MemoryHandler</code></a> is a subclass of the more general <a class="reference internal" href="#logging.handlers.BufferingHandler" title="logging.handlers.BufferingHandler"><code>BufferingHandler</code></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 <code>shouldFlush()</code> to see if the buffer should be flushed. If it should, then <code>flush()</code> is expected to do the flushing.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.BufferingHandler"> +<code>class logging.handlers.BufferingHandler(capacity)</code> </dt> <dd> +<p>Initializes the handler with a buffer of the specified capacity. Here, <em>capacity</em> means the number of logging records buffered.</p> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.BufferingHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Append the record to the buffer. If <a class="reference internal" href="#logging.handlers.BufferingHandler.shouldFlush" title="logging.handlers.BufferingHandler.shouldFlush"><code>shouldFlush()</code></a> returns true, call <a class="reference internal" href="#logging.handlers.BufferingHandler.flush" title="logging.handlers.BufferingHandler.flush"><code>flush()</code></a> to process the buffer.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.BufferingHandler.flush"> +<code>flush()</code> </dt> <dd> +<p>For a <a class="reference internal" href="#logging.handlers.BufferingHandler" title="logging.handlers.BufferingHandler"><code>BufferingHandler</code></a> instance, flushing means that it sets the buffer to an empty list. This method can be overwritten to implement more useful flushing behavior.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.BufferingHandler.shouldFlush"> +<code>shouldFlush(record)</code> </dt> <dd> +<p>Return <code>True</code> if the buffer is up to capacity. This method can be overridden to implement custom flushing strategies.</p> </dd> +</dl> </dd> +</dl> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.MemoryHandler"> +<code>class logging.handlers.MemoryHandler(capacity, flushLevel=ERROR, target=None, flushOnClose=True)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.MemoryHandler" title="logging.handlers.MemoryHandler"><code>MemoryHandler</code></a> class. The instance is initialized with a buffer size of <em>capacity</em> (number of records buffered). If <em>flushLevel</em> is not specified, <code>ERROR</code> is used. If no <em>target</em> is specified, the target will need to be set using <a class="reference internal" href="#logging.handlers.MemoryHandler.setTarget" title="logging.handlers.MemoryHandler.setTarget"><code>setTarget()</code></a> before this handler does anything useful. If <em>flushOnClose</em> is specified as <code>False</code>, then the buffer is <em>not</em> flushed when the handler is closed. If not specified or specified as <code>True</code>, the previous behaviour of flushing the buffer will occur when the handler is closed.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.6: </span>The <em>flushOnClose</em> parameter was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.MemoryHandler.close"> +<code>close()</code> </dt> <dd> +<p>Calls <a class="reference internal" href="#logging.handlers.MemoryHandler.flush" title="logging.handlers.MemoryHandler.flush"><code>flush()</code></a>, sets the target to <code>None</code> and clears the buffer.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.MemoryHandler.flush"> +<code>flush()</code> </dt> <dd> +<p>For a <a class="reference internal" href="#logging.handlers.MemoryHandler" title="logging.handlers.MemoryHandler"><code>MemoryHandler</code></a> instance, flushing means just sending the buffered records to the target, if there is one. The buffer is also cleared when buffered records are sent to the target. Override if you want different behavior.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.MemoryHandler.setTarget"> +<code>setTarget(target)</code> </dt> <dd> +<p>Sets the target handler for this handler.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.MemoryHandler.shouldFlush"> +<code>shouldFlush(record)</code> </dt> <dd> +<p>Checks for buffer full or a record at the <em>flushLevel</em> or higher.</p> </dd> +</dl> </dd> +</dl> </section> <section id="httphandler"> <span id="http-handler"></span><h2>HTTPHandler</h2> <p>The <a class="reference internal" href="#logging.handlers.HTTPHandler" title="logging.handlers.HTTPHandler"><code>HTTPHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports sending logging messages to a web server, using either <code>GET</code> or <code>POST</code> semantics.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.HTTPHandler"> +<code>class logging.handlers.HTTPHandler(host, url, method='GET', secure=False, credentials=None, context=None)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.HTTPHandler" title="logging.handlers.HTTPHandler"><code>HTTPHandler</code></a> class. The <em>host</em> can be of the form <code>host:port</code>, should you need to use a specific port number. If no <em>method</em> is specified, <code>GET</code> is used. If <em>secure</em> is true, a HTTPS connection will be used. The <em>context</em> parameter may be set to a <a class="reference internal" href="ssl#ssl.SSLContext" title="ssl.SSLContext"><code>ssl.SSLContext</code></a> instance to configure the SSL settings used for the HTTPS connection. If <em>credentials</em> is specified, it should be a 2-tuple consisting of userid and password, which will be placed in a HTTP ‘Authorization’ header using Basic authentication. If you specify credentials, you should also specify secure=True so that your userid and password are not passed in cleartext across the wire.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.5: </span>The <em>context</em> parameter was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.HTTPHandler.mapLogRecord"> +<code>mapLogRecord(record)</code> </dt> <dd> +<p>Provides a dictionary, based on <code>record</code>, which is to be URL-encoded and sent to the web server. The default implementation just returns <code>record.__dict__</code>. This method can be overridden if e.g. only a subset of <a class="reference internal" href="logging#logging.LogRecord" title="logging.LogRecord"><code>LogRecord</code></a> is to be sent to the web server, or if more specific customization of what’s sent to the server is required.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.HTTPHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Sends the record to the web server as a URL-encoded dictionary. The <a class="reference internal" href="#logging.handlers.HTTPHandler.mapLogRecord" title="logging.handlers.HTTPHandler.mapLogRecord"><code>mapLogRecord()</code></a> method is used to convert the record to the dictionary to be sent.</p> </dd> +</dl> <div class="admonition note"> <p class="admonition-title">Note</p> <p>Since preparing a record for sending it to a web server is not the same as a generic formatting operation, using <a class="reference internal" href="logging#logging.Handler.setFormatter" title="logging.Handler.setFormatter"><code>setFormatter()</code></a> to specify a <a class="reference internal" href="logging#logging.Formatter" title="logging.Formatter"><code>Formatter</code></a> for a <a class="reference internal" href="#logging.handlers.HTTPHandler" title="logging.handlers.HTTPHandler"><code>HTTPHandler</code></a> has no effect. Instead of calling <a class="reference internal" href="logging#logging.Handler.format" title="logging.Handler.format"><code>format()</code></a>, this handler calls <a class="reference internal" href="#logging.handlers.HTTPHandler.mapLogRecord" title="logging.handlers.HTTPHandler.mapLogRecord"><code>mapLogRecord()</code></a> and then <a class="reference internal" href="urllib.parse#urllib.parse.urlencode" title="urllib.parse.urlencode"><code>urllib.parse.urlencode()</code></a> to encode the dictionary in a form suitable for sending to a web server.</p> </div> </dd> +</dl> </section> <section id="queuehandler"> <span id="queue-handler"></span><h2>QueueHandler</h2> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.2.</span></p> </div> <p>The <a class="reference internal" href="#logging.handlers.QueueHandler" title="logging.handlers.QueueHandler"><code>QueueHandler</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports sending logging messages to a queue, such as those implemented in the <a class="reference internal" href="queue#module-queue" title="queue: A synchronized queue class."><code>queue</code></a> or <a class="reference internal" href="multiprocessing#module-multiprocessing" title="multiprocessing: Process-based parallelism."><code>multiprocessing</code></a> modules.</p> <p>Along with the <a class="reference internal" href="#logging.handlers.QueueListener" title="logging.handlers.QueueListener"><code>QueueListener</code></a> class, <a class="reference internal" href="#logging.handlers.QueueHandler" title="logging.handlers.QueueHandler"><code>QueueHandler</code></a> can be used to let handlers do their work on a separate thread from the one which does the logging. This is important in web applications and also other service applications where threads servicing clients need to respond as quickly as possible, while any potentially slow operations (such as sending an email via <a class="reference internal" href="#logging.handlers.SMTPHandler" title="logging.handlers.SMTPHandler"><code>SMTPHandler</code></a>) are done on a separate thread.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.QueueHandler"> +<code>class logging.handlers.QueueHandler(queue)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.QueueHandler" title="logging.handlers.QueueHandler"><code>QueueHandler</code></a> class. The instance is initialized with the queue to send messages to. The <em>queue</em> can be any queue-like object; it’s used as-is by the <a class="reference internal" href="#logging.handlers.QueueHandler.enqueue" title="logging.handlers.QueueHandler.enqueue"><code>enqueue()</code></a> method, which needs to know how to send messages to it. The queue is not <em>required</em> to have the task tracking API, which means that you can use <a class="reference internal" href="queue#queue.SimpleQueue" title="queue.SimpleQueue"><code>SimpleQueue</code></a> instances for <em>queue</em>.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>If you are using <a class="reference internal" href="multiprocessing#module-multiprocessing" title="multiprocessing: Process-based parallelism."><code>multiprocessing</code></a>, you should avoid using <a class="reference internal" href="queue#queue.SimpleQueue" title="queue.SimpleQueue"><code>SimpleQueue</code></a> and instead use <a class="reference internal" href="multiprocessing#multiprocessing.Queue" title="multiprocessing.Queue"><code>multiprocessing.Queue</code></a>.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueHandler.emit"> +<code>emit(record)</code> </dt> <dd> +<p>Enqueues the result of preparing the LogRecord. Should an exception occur (e.g. because a bounded queue has filled up), the <a class="reference internal" href="logging#logging.Handler.handleError" title="logging.Handler.handleError"><code>handleError()</code></a> method is called to handle the error. This can result in the record silently being dropped (if <code>logging.raiseExceptions</code> is <code>False</code>) or a message printed to <code>sys.stderr</code> (if <code>logging.raiseExceptions</code> is <code>True</code>).</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueHandler.prepare"> +<code>prepare(record)</code> </dt> <dd> +<p>Prepares a record for queuing. The object returned by this method is enqueued.</p> <p>The base implementation formats the record to merge the message, arguments, exception and stack information, if present. It also removes unpickleable items from the record in-place. Specifically, it overwrites the record’s <code>msg</code> and <code>message</code> attributes with the merged message (obtained by calling the handler’s <a class="reference internal" href="functions#format" title="format"><code>format()</code></a> method), and sets the <code>args</code>, <code>exc_info</code> and <code>exc_text</code> attributes to <code>None</code>.</p> <p>You might want to override this method if you want to convert the record to a dict or JSON string, or send a modified copy of the record while leaving the original intact.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>The base implementation formats the message with arguments, sets the <code>message</code> and <code>msg</code> attributes to the formatted message and sets the <code>args</code> and <code>exc_text</code> attributes to <code>None</code> to allow pickling and to prevent further attempts at formatting. This means that a handler on the <a class="reference internal" href="#logging.handlers.QueueListener" title="logging.handlers.QueueListener"><code>QueueListener</code></a> side won’t have the information to do custom formatting, e.g. of exceptions. You may wish to subclass <code>QueueHandler</code> and override this method to e.g. avoid setting <code>exc_text</code> to <code>None</code>. Note that the <code>message</code> / <code>msg</code> / <code>args</code> changes are related to ensuring the record is pickleable, and you might or might not be able to avoid doing that depending on whether your <code>args</code> are pickleable. (Note that you may have to consider not only your own code but also code in any libraries that you use.)</p> </div> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueHandler.enqueue"> +<code>enqueue(record)</code> </dt> <dd> +<p>Enqueues the record on the queue using <code>put_nowait()</code>; you may want to override this if you want to use blocking behaviour, or a timeout, or a customized queue implementation.</p> </dd> +</dl> <dl class="py attribute"> <dt class="sig sig-object py" id="logging.handlers.QueueHandler.listener"> +<code>listener</code> </dt> <dd> +<p>When created via configuration using <a class="reference internal" href="logging.config#logging.config.dictConfig" title="logging.config.dictConfig"><code>dictConfig()</code></a>, this attribute will contain a <a class="reference internal" href="#logging.handlers.QueueListener" title="logging.handlers.QueueListener"><code>QueueListener</code></a> instance for use with this handler. Otherwise, it will be <code>None</code>.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.12.</span></p> </div> </dd> +</dl> </dd> +</dl> </section> <section id="queuelistener"> <span id="queue-listener"></span><h2>QueueListener</h2> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.2.</span></p> </div> <p>The <a class="reference internal" href="#logging.handlers.QueueListener" title="logging.handlers.QueueListener"><code>QueueListener</code></a> class, located in the <a class="reference internal" href="#module-logging.handlers" title="logging.handlers: Handlers for the logging module."><code>logging.handlers</code></a> module, supports receiving logging messages from a queue, such as those implemented in the <a class="reference internal" href="queue#module-queue" title="queue: A synchronized queue class."><code>queue</code></a> or <a class="reference internal" href="multiprocessing#module-multiprocessing" title="multiprocessing: Process-based parallelism."><code>multiprocessing</code></a> modules. The messages are received from a queue in an internal thread and passed, on the same thread, to one or more handlers for processing. While <a class="reference internal" href="#logging.handlers.QueueListener" title="logging.handlers.QueueListener"><code>QueueListener</code></a> is not itself a handler, it is documented here because it works hand-in-hand with <a class="reference internal" href="#logging.handlers.QueueHandler" title="logging.handlers.QueueHandler"><code>QueueHandler</code></a>.</p> <p>Along with the <a class="reference internal" href="#logging.handlers.QueueHandler" title="logging.handlers.QueueHandler"><code>QueueHandler</code></a> class, <a class="reference internal" href="#logging.handlers.QueueListener" title="logging.handlers.QueueListener"><code>QueueListener</code></a> can be used to let handlers do their work on a separate thread from the one which does the logging. This is important in web applications and also other service applications where threads servicing clients need to respond as quickly as possible, while any potentially slow operations (such as sending an email via <a class="reference internal" href="#logging.handlers.SMTPHandler" title="logging.handlers.SMTPHandler"><code>SMTPHandler</code></a>) are done on a separate thread.</p> <dl class="py class"> <dt class="sig sig-object py" id="logging.handlers.QueueListener"> +<code>class logging.handlers.QueueListener(queue, *handlers, respect_handler_level=False)</code> </dt> <dd> +<p>Returns a new instance of the <a class="reference internal" href="#logging.handlers.QueueListener" title="logging.handlers.QueueListener"><code>QueueListener</code></a> class. The instance is initialized with the queue to send messages to and a list of handlers which will handle entries placed on the queue. The queue can be any queue-like object; it’s passed as-is to the <a class="reference internal" href="#logging.handlers.QueueListener.dequeue" title="logging.handlers.QueueListener.dequeue"><code>dequeue()</code></a> method, which needs to know how to get messages from it. The queue is not <em>required</em> to have the task tracking API (though it’s used if available), which means that you can use <a class="reference internal" href="queue#queue.SimpleQueue" title="queue.SimpleQueue"><code>SimpleQueue</code></a> instances for <em>queue</em>.</p> <div class="admonition note"> <p class="admonition-title">Note</p> <p>If you are using <a class="reference internal" href="multiprocessing#module-multiprocessing" title="multiprocessing: Process-based parallelism."><code>multiprocessing</code></a>, you should avoid using <a class="reference internal" href="queue#queue.SimpleQueue" title="queue.SimpleQueue"><code>SimpleQueue</code></a> and instead use <a class="reference internal" href="multiprocessing#multiprocessing.Queue" title="multiprocessing.Queue"><code>multiprocessing.Queue</code></a>.</p> </div> <p>If <code>respect_handler_level</code> is <code>True</code>, a handler’s level is respected (compared with the level for the message) when deciding whether to pass messages to that handler; otherwise, the behaviour is as in previous Python versions - to always pass each message to each handler.</p> <div class="versionchanged"> <p><span class="versionmodified changed">Changed in version 3.5: </span>The <code>respect_handler_level</code> argument was added.</p> </div> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueListener.dequeue"> +<code>dequeue(block)</code> </dt> <dd> +<p>Dequeues a record and return it, optionally blocking.</p> <p>The base implementation uses <code>get()</code>. You may want to override this method if you want to use timeouts or work with custom queue implementations.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueListener.prepare"> +<code>prepare(record)</code> </dt> <dd> +<p>Prepare a record for handling.</p> <p>This implementation just returns the passed-in record. You may want to override this method if you need to do any custom marshalling or manipulation of the record before passing it to the handlers.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueListener.handle"> +<code>handle(record)</code> </dt> <dd> +<p>Handle a record.</p> <p>This just loops through the handlers offering them the record to handle. The actual object passed to the handlers is that which is returned from <a class="reference internal" href="#logging.handlers.QueueListener.prepare" title="logging.handlers.QueueListener.prepare"><code>prepare()</code></a>.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueListener.start"> +<code>start()</code> </dt> <dd> +<p>Starts the listener.</p> <p>This starts up a background thread to monitor the queue for LogRecords to process.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueListener.stop"> +<code>stop()</code> </dt> <dd> +<p>Stops the listener.</p> <p>This asks the thread to terminate, and then waits for it to do so. Note that if you don’t call this before your application exits, there may be some records still left on the queue, which won’t be processed.</p> </dd> +</dl> <dl class="py method"> <dt class="sig sig-object py" id="logging.handlers.QueueListener.enqueue_sentinel"> +<code>enqueue_sentinel()</code> </dt> <dd> +<p>Writes a sentinel to the queue to tell the listener to quit. This implementation uses <code>put_nowait()</code>. You may want to override this method if you want to use timeouts or work with custom queue implementations.</p> <div class="versionadded"> <p><span class="versionmodified added">New in version 3.3.</span></p> </div> </dd> +</dl> </dd> +</dl> <div class="admonition seealso"> <p class="admonition-title">See also</p> <dl class="simple"> <dt> +<code>Module</code> <a class="reference internal" href="logging#module-logging" title="logging: Flexible event logging system for applications."><code>logging</code></a> +</dt> +<dd> +<p>API reference for the logging module.</p> </dd> <dt> +<code>Module</code> <a class="reference internal" href="logging.config#module-logging.config" title="logging.config: Configuration of the logging module."><code>logging.config</code></a> +</dt> +<dd> +<p>Configuration API for the logging module.</p> </dd> </dl> </div> </section> <div class="_attribution"> + <p class="_attribution-p"> + © 2001–2023 Python Software Foundation<br>Licensed under the PSF License.<br> + <a href="https://docs.python.org/3.12/library/logging.handlers.html" class="_attribution-link">https://docs.python.org/3.12/library/logging.handlers.html</a> + </p> +</div> |