Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(3)

Unified Diff: Doc/howto/logging.rst

Issue 18759: Fix internal doc references for logging package (Closed)
Patch Set: Created 6 years, 6 months ago
Use n/p to move between diff chunks; N/P to move between comments. Please Sign in to add in-line comments.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « Doc/howto/logging-cookbook.rst ('k') | Doc/library/logging.config.rst » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
--- a/Doc/howto/logging.rst Fri Aug 16 19:36:18 2013 +0200
+++ b/Doc/howto/logging.rst Fri Aug 16 22:21:58 2013 +0300
@@ -469,8 +469,9 @@
:class:`~logging.Handler` objects are responsible for dispatching the
appropriate log messages (based on the log messages' severity) to the handler's
-specified destination. Logger objects can add zero or more handler objects to
-themselves with an :func:`addHandler` method. As an example scenario, an
+specified destination. :class:`Logger` objects can add zero or more handler
+objects to themselves with an :meth:`~Logger.addHandler` 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
@@ -491,10 +492,11 @@
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.
-* :func:`setFormatter` selects a Formatter object for this handler to use.
+* :func:`~Handler.setFormatter` selects a Formatter object for this handler to
+ use.
-* :func:`addFilter` and :func:`removeFilter` respectively configure and
- deconfigure filter objects on handlers.
+* :func:`~Handler.addFilter` and :func:`~Handler.removeFilter` respectively
+ configure and deconfigure filter objects on handlers.
Application code should not directly instantiate and use instances of
:class:`Handler`. Instead, the :class:`Handler` class is a base class that
@@ -954,7 +956,8 @@
When filtering based on logger level and/or handler level is not enough,
instances of :class:`Filter` can be added to both :class:`Logger` and
-:class:`Handler` instances (through their :meth:`addFilter` method). Before
+:class:`Handler` instances (through their :meth:`Handler.addFilter` 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.
@@ -975,12 +978,14 @@
cause the application using logging to terminate prematurely.
:class:`SystemExit` and :class:`KeyboardInterrupt` exceptions are never
-swallowed. Other exceptions which occur during the :meth:`emit` method of a
-:class:`Handler` subclass are passed to its :meth:`handleError` method.
+swallowed. Other exceptions which occur during the :meth:`~Handler.emit` method
+of a
+:class:`Handler` subclass are passed to its :meth:`~Handler.handleError` method.
-The default implementation of :meth:`handleError` in :class:`Handler` checks
-to see if a module-level variable, :data:`raiseExceptions`, is set. If set, a
-traceback is printed to :data:`sys.stderr`. If not set, the exception is swallowed.
+The default implementation of :meth:`~Handler.handleError` in :class:`Handler`
+checks to see if a module-level variable, :data:`raiseExceptions`, is set. If
+set, a traceback is printed to :data:`sys.stderr`. If not set, the exception is
+swallowed.
.. note:: The default value of :data:`raiseExceptions` is ``True``. This is
because during development, you typically want to be notified of any
@@ -997,11 +1002,12 @@
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
-:meth:`__str__` method will be called when the logging system needs to convert
+:meth:`~object.__str__` 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
-:class:`SocketHandler` emits an event by pickling it and sending it over the
-wire.
+:class:`~handlers.SocketHandler` emits an event by pickling it and sending it
+over the wire.
Optimization
@@ -1010,7 +1016,8 @@
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 :meth:`isEnabledFor`
+away your event. To decide what to do, you can call the
+:meth:`~Logger.isEnabledFor`
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::
« no previous file with comments | « Doc/howto/logging-cookbook.rst ('k') | Doc/library/logging.config.rst » ('j') | no next file with comments »

RSS Feeds Recent Issues | This issue
This is Rietveld 894c83f36cb7+