Skip to content

Commit b89cfa1

Browse files
committed
Fix redundant docs for Logger.debug and logging.debug
1 parent 6f4163f commit b89cfa1

File tree

1 file changed

+24
-83
lines changed

1 file changed

+24
-83
lines changed

Doc/library/logging.rst

Lines changed: 24 additions & 83 deletions
Original file line numberDiff line numberDiff line change
@@ -1112,89 +1112,30 @@ functions.
11121112

11131113
.. function:: debug(msg, *args, **kwargs)
11141114

1115-
Logs a message with level :const:`DEBUG` on the root logger. The *msg* is the
1116-
message format string, and the *args* are the arguments which are merged into
1117-
*msg* using the string formatting operator. (Note that this means that you can
1118-
use keywords in the format string, together with a single dictionary argument.)
1119-
1120-
There are three keyword arguments in *kwargs* which are inspected: *exc_info*
1121-
which, if it does not evaluate as false, causes exception information to be
1122-
added to the logging message. If an exception tuple (in the format returned by
1123-
:func:`sys.exc_info`) or an exception instance is provided, it is used;
1124-
otherwise, :func:`sys.exc_info` is called to get the exception information.
1125-
1126-
The second optional keyword argument is *stack_info*, which defaults to
1127-
``False``. If true, stack information is added to the logging
1128-
message, including the actual logging call. Note that this is not the same
1129-
stack information as that displayed through specifying *exc_info*: The
1130-
former is stack frames from the bottom of the stack up to the logging call
1131-
in the current thread, whereas the latter is information about stack frames
1132-
which have been unwound, following an exception, while searching for
1133-
exception handlers.
1134-
1135-
You can specify *stack_info* independently of *exc_info*, e.g. to just show
1136-
how you got to a certain point in your code, even when no exceptions were
1137-
raised. The stack frames are printed following a header line which says:
1138-
1139-
.. code-block:: none
1140-
1141-
Stack (most recent call last):
1142-
1143-
This mimics the ``Traceback (most recent call last):`` which is used when
1144-
displaying exception frames.
1145-
1146-
The third optional keyword argument is *extra* which can be used to pass a
1147-
dictionary which is used to populate the __dict__ of the LogRecord created for
1148-
the logging event with user-defined attributes. These custom attributes can then
1149-
be used as you like. For example, they could be incorporated into logged
1150-
messages. For example::
1151-
1152-
FORMAT = '%(asctime)s %(clientip)-15s %(user)-8s %(message)s'
1153-
logging.basicConfig(format=FORMAT)
1154-
d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
1155-
logging.warning('Protocol problem: %s', 'connection reset', extra=d)
1156-
1157-
would print something like:
1158-
1159-
.. code-block:: none
1160-
1161-
2006-02-08 22:20:02,165 192.168.0.1 fbloggs Protocol problem: connection reset
1162-
1163-
The keys in the dictionary passed in *extra* should not clash with the keys used
1164-
by the logging system. (See the :class:`Formatter` documentation for more
1165-
information on which keys are used by the logging system.)
1166-
1167-
If you choose to use these attributes in logged messages, you need to exercise
1168-
some care. In the above example, for instance, the :class:`Formatter` has been
1169-
set up with a format string which expects 'clientip' and 'user' in the attribute
1170-
dictionary of the LogRecord. If these are missing, the message will not be
1171-
logged because a string formatting exception will occur. So in this case, you
1172-
always need to pass the *extra* dictionary with these keys.
1173-
1174-
While this might be annoying, this feature is intended for use in specialized
1175-
circumstances, such as multi-threaded servers where the same code executes in
1176-
many contexts, and interesting conditions which arise are dependent on this
1177-
context (such as remote client IP address and authenticated user name, in the
1178-
above example). In such circumstances, it is likely that specialized
1179-
:class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
1180-
1181-
This function (as well as :func:`info`, :func:`warning`, :func:`error` and
1182-
:func:`critical`) will call :func:`basicConfig` if the root logger doesn't
1183-
have any handler attached.
1115+
This is a convenience function that calls ``Logger.debug``, using the root
1116+
logger as the Logger. The handling of the arguments is in every way identical
1117+
to what is described in that function.
1118+
1119+
The only difference is that if the root logger has no handlers, then
1120+
:func:`basicConfig` is called, prior to calling ``debug`` on the root logger.
1121+
1122+
For very short scripts or quick demonstrations of ``logging`` facilities, ``debug``
1123+
and the other module level functions may be convenient. However, most programs
1124+
will want to carefully and explicitly control the setup of the root logger, and
1125+
should prefer creating a module-level logger and calling ``Logger.debug`` on it,
1126+
as described at the beginnning of this documentation.
11841127

1185-
.. versionchanged:: 3.2
1186-
The *stack_info* parameter was added.
11871128

11881129
.. function:: info(msg, *args, **kwargs)
11891130

1190-
Logs a message with level :const:`INFO` on the root logger. The arguments are
1191-
interpreted as for :func:`debug`.
1131+
Logs a message with level :const:`INFO` on the root logger. The arguments and behavior
1132+
are otherwise the same as for :func:`debug`.
11921133

11931134

11941135
.. function:: warning(msg, *args, **kwargs)
11951136

1196-
Logs a message with level :const:`WARNING` on the root logger. The arguments
1197-
are interpreted as for :func:`debug`.
1137+
Logs a message with level :const:`WARNING` on the root logger. The arguments and behavior
1138+
are the otherwise same as for :func:`debug`.
11981139

11991140
.. note:: There is an obsolete function ``warn`` which is functionally
12001141
identical to ``warning``. As ``warn`` is deprecated, please do not use
@@ -1203,26 +1144,26 @@ functions.
12031144

12041145
.. function:: error(msg, *args, **kwargs)
12051146

1206-
Logs a message with level :const:`ERROR` on the root logger. The arguments are
1207-
interpreted as for :func:`debug`.
1147+
Logs a message with level :const:`ERROR` on the root logger. The arguments and behavior
1148+
are the otherwise same as for :func:`debug`.
12081149

12091150

12101151
.. function:: critical(msg, *args, **kwargs)
12111152

1212-
Logs a message with level :const:`CRITICAL` on the root logger. The arguments
1213-
are interpreted as for :func:`debug`.
1153+
Logs a message with level :const:`CRITICAL` on the root logger. The arguments and behavior
1154+
are the otherwise same as for :func:`debug`.
12141155

12151156

12161157
.. function:: exception(msg, *args, **kwargs)
12171158

1218-
Logs a message with level :const:`ERROR` on the root logger. The arguments are
1219-
interpreted as for :func:`debug`. Exception info is added to the logging
1159+
Logs a message with level :const:`ERROR` on the root logger. The arguments and behavior
1160+
are the otherwise same as for :func:`debug`. Exception info is added to the logging
12201161
message. This function should only be called from an exception handler.
12211162

12221163
.. function:: log(level, msg, *args, **kwargs)
12231164

1224-
Logs a message with level *level* on the root logger. The other arguments are
1225-
interpreted as for :func:`debug`.
1165+
Logs a message with level *level* on the root logger. The arguments and behavior
1166+
are the otherwise same as for :func:`debug`.
12261167

12271168
.. function:: disable(level=CRITICAL)
12281169

0 commit comments

Comments
 (0)