@@ -518,7 +518,7 @@ custom handlers) are the following configuration methods:
518
518
519
519
* The :meth: `~Handler.setLevel ` method, just as in logger objects, specifies the
520
520
lowest severity that will be dispatched to the appropriate destination. Why
521
- are there two :func: ` setLevel ` methods? The level set in the logger
521
+ are there two :meth: ` ~Handler. setLevel ` methods? The level set in the logger
522
522
determines which severity of messages it will pass to its handlers. The level
523
523
set in each handler determines which messages that handler will send on.
524
524
@@ -772,29 +772,29 @@ What happens if no configuration is provided
772
772
773
773
If no logging configuration is provided, it is possible to have a situation
774
774
where a logging event needs to be output, but no handlers can be found to
775
- output the event. The behaviour of the logging package in these
776
- circumstances is dependent on the Python version.
775
+ output the event.
777
776
778
- For versions of Python prior to 3.2, the behaviour is as follows:
777
+ The event is output using a 'handler of last resort', stored in
778
+ :data: `lastResort `. This internal handler is not associated with any
779
+ logger, and acts like a :class: `~logging.StreamHandler ` which writes the
780
+ event description message to the current value of ``sys.stderr `` (therefore
781
+ respecting any redirections which may be in effect). No formatting is
782
+ done on the message - just the bare event description message is printed.
783
+ The handler's level is set to ``WARNING ``, so all events at this and
784
+ greater severities will be output.
779
785
780
- * If *logging.raiseExceptions * is ``False `` (production mode), the event is
781
- silently dropped.
786
+ .. versionchanged :: 3.2
782
787
783
- * If *logging.raiseExceptions * is ``True `` (development mode), a message
784
- 'No handlers could be found for logger X.Y.Z' is printed once.
788
+ For versions of Python prior to 3.2, the behaviour is as follows:
785
789
786
- In Python 3.2 and later, the behaviour is as follows:
790
+ * If :data: `raiseExceptions ` is ``False `` (production mode), the event is
791
+ silently dropped.
787
792
788
- * The event is output using a 'handler of last resort', stored in
789
- ``logging.lastResort ``. This internal handler is not associated with any
790
- logger, and acts like a :class: `~logging.StreamHandler ` which writes the
791
- event description message to the current value of ``sys.stderr `` (therefore
792
- respecting any redirections which may be in effect). No formatting is
793
- done on the message - just the bare event description message is printed.
794
- The handler's level is set to ``WARNING ``, so all events at this and
795
- greater severities will be output.
793
+ * If :data: `raiseExceptions ` is ``True `` (development mode), a message
794
+ 'No handlers could be found for logger X.Y.Z' is printed once.
796
795
797
- To obtain the pre-3.2 behaviour, ``logging.lastResort `` can be set to ``None ``.
796
+ To obtain the pre-3.2 behaviour,
797
+ :data: `lastResort ` can be set to ``None ``.
798
798
799
799
.. _library-config :
800
800
@@ -996,7 +996,7 @@ Logged messages are formatted for presentation through instances of the
996
996
use with the % operator and a dictionary.
997
997
998
998
For formatting multiple messages in a batch, instances of
999
- :class: `~handlers. BufferingFormatter ` can be used. In addition to the format
999
+ :class: `BufferingFormatter ` can be used. In addition to the format
1000
1000
string (which is applied to each message in the batch), there is provision for
1001
1001
header and trailer format strings.
1002
1002
@@ -1032,7 +1032,8 @@ checks to see if a module-level variable, :data:`raiseExceptions`, is set. If
1032
1032
set, a traceback is printed to :data: `sys.stderr `. If not set, the exception is
1033
1033
swallowed.
1034
1034
1035
- .. note :: The default value of :data:`raiseExceptions` is ``True``. This is
1035
+ .. note ::
1036
+ The default value of :data: `raiseExceptions ` is ``True ``. This is
1036
1037
because during development, you typically want to be notified of any
1037
1038
exceptions that occur. It's advised that you set :data: `raiseExceptions ` to
1038
1039
``False `` for production usage.
@@ -1070,7 +1071,7 @@ You can write code like this::
1070
1071
expensive_func2())
1071
1072
1072
1073
so that if the logger's threshold is set above ``DEBUG ``, the calls to
1073
- :func: ` expensive_func1 ` and :func: ` expensive_func2 ` are never made.
1074
+ `` expensive_func1 `` and `` expensive_func2 ` ` are never made.
1074
1075
1075
1076
.. note :: In some cases, :meth:`~Logger.isEnabledFor` can itself be more
1076
1077
expensive than you'd like (e.g. for deeply nested loggers where an explicit
0 commit comments