mirror of
https://github.com/python/cpython.git
synced 2025-08-03 16:39:00 +00:00
gh-101100: Fix Sphinx warnings in the Logging Cookbook (#108678)
This commit is contained in:
parent
38ab0dba80
commit
c7cef54631
2 changed files with 11 additions and 5 deletions
|
@ -761,7 +761,7 @@ printed on the console; on the server side, you should see something like:
|
|||
|
||||
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 :meth:`~handlers.SocketHandler.makePickle` method and implementing your
|
||||
the :meth:`~SocketHandler.makePickle` method and implementing your
|
||||
alternative there, as well as adapting the above script to use your alternative
|
||||
serialization.
|
||||
|
||||
|
@ -835,6 +835,8 @@ To test these files, do the following in a POSIX environment:
|
|||
You may need to tweak the configuration files in the unlikely event that the
|
||||
configured ports clash with something else in your test environment.
|
||||
|
||||
.. currentmodule:: logging
|
||||
|
||||
.. _context-info:
|
||||
|
||||
Adding contextual information to your logging output
|
||||
|
@ -1546,7 +1548,7 @@ Sometimes you want to let a log file grow to a certain size, then open a new
|
|||
file and log to that. You may want to keep a certain number of these files, and
|
||||
when that many files have been created, rotate the files so that the number of
|
||||
files and the size of the files both remain bounded. For this usage pattern, the
|
||||
logging package provides a :class:`~handlers.RotatingFileHandler`::
|
||||
logging package provides a :class:`RotatingFileHandler`::
|
||||
|
||||
import glob
|
||||
import logging
|
||||
|
@ -1594,6 +1596,8 @@ and each time it reaches the size limit it is renamed with the suffix
|
|||
Obviously this example sets the log length much too small as an extreme
|
||||
example. You would want to set *maxBytes* to an appropriate value.
|
||||
|
||||
.. currentmodule:: logging
|
||||
|
||||
.. _format-styles:
|
||||
|
||||
Use of alternative formatting styles
|
||||
|
@ -1840,6 +1844,7 @@ However, it should be borne in mind that each link in the chain adds run-time
|
|||
overhead to all logging operations, and the technique should only be used when
|
||||
the use of a :class:`Filter` does not provide the desired result.
|
||||
|
||||
.. currentmodule:: logging.handlers
|
||||
|
||||
.. _zeromq-handlers:
|
||||
|
||||
|
@ -1917,6 +1922,8 @@ of queues, for example a ZeroMQ 'subscribe' socket. Here's an example::
|
|||
:ref:`A more advanced logging tutorial <logging-advanced-tutorial>`
|
||||
|
||||
|
||||
.. currentmodule:: logging
|
||||
|
||||
An example dictionary-based configuration
|
||||
-----------------------------------------
|
||||
|
||||
|
@ -3918,8 +3925,8 @@ that in other languages such as Java and C#, loggers are often static class
|
|||
attributes. However, this pattern doesn't make sense in Python, where the
|
||||
module (and not the class) is the unit of software decomposition.
|
||||
|
||||
Adding handlers other than :class:`NullHandler` to a logger in a library
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Adding handlers other than :class:`~logging.NullHandler` to a logger in a library
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Configuring logging by adding handlers, formatters and filters is the
|
||||
responsibility of the application developer, not the library developer. If you
|
||||
|
|
|
@ -26,7 +26,6 @@ Doc/glossary.rst
|
|||
Doc/howto/descriptor.rst
|
||||
Doc/howto/enum.rst
|
||||
Doc/howto/isolating-extensions.rst
|
||||
Doc/howto/logging-cookbook.rst
|
||||
Doc/howto/logging.rst
|
||||
Doc/howto/urllib2.rst
|
||||
Doc/library/__future__.rst
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue