mirror of
https://github.com/python/cpython.git
synced 2025-11-01 18:51:43 +00:00
bpo-35722: Updated the documentation for the 'disable_existing_loggers' parameter (GH-11525)
This commit is contained in:
parent
da6424e96a
commit
f0c743604f
2 changed files with 10 additions and 10 deletions
|
|
@ -695,15 +695,15 @@ noncoders to easily modify the logging properties.
|
|||
.. warning:: The :func:`fileConfig` function takes a default parameter,
|
||||
``disable_existing_loggers``, which defaults to ``True`` for reasons of
|
||||
backward compatibility. This may or may not be what you want, since it
|
||||
will cause any loggers existing before the :func:`fileConfig` call to
|
||||
be disabled unless they (or an ancestor) are explicitly named in the
|
||||
configuration. Please refer to the reference documentation for more
|
||||
will cause any non-root loggers existing before the :func:`fileConfig`
|
||||
call to be disabled unless they (or an ancestor) are explicitly named in
|
||||
the configuration. Please refer to the reference documentation for more
|
||||
information, and specify ``False`` for this parameter if you wish.
|
||||
|
||||
The dictionary passed to :func:`dictConfig` can also specify a Boolean
|
||||
value with key ``disable_existing_loggers``, which if not specified
|
||||
explicitly in the dictionary also defaults to being interpreted as
|
||||
``True``. This leads to the logger-disabling behaviour described above,
|
||||
``True``. This leads to the logger-disabling behaviour described above,
|
||||
which may not be what you want - in which case, provide the key
|
||||
explicitly with a value of ``False``.
|
||||
|
||||
|
|
@ -802,7 +802,7 @@ the best default behaviour.
|
|||
If for some reason you *don't* want these messages printed in the absence of
|
||||
any logging configuration, you can attach a do-nothing handler to the top-level
|
||||
logger for your library. This avoids the message being printed, since a handler
|
||||
will be always be found for the library's events: it just doesn't produce any
|
||||
will always be found for the library's events: it just doesn't produce any
|
||||
output. If the library user configures logging for application use, presumably
|
||||
that configuration will add some handlers, and if levels are suitably
|
||||
configured then logging calls made in library code will send output to those
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue