From 2efc832cdfa7eec5905b11dbf0b6855aa0f6447d Mon Sep 17 00:00:00 2001 From: Kal Sze Date: Thu, 18 Apr 2019 10:58:13 +0800 Subject: [PATCH] [3.0.x] More accurate terminology ("logger" instead of "logging handler") in logging documentation. Backport of aa6c620249bc8c2a6245c8d7b928b05e7e5e78fc from master --- docs/topics/logging.txt | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt index b8b3162fe5..80348e360b 100644 --- a/docs/topics/logging.txt +++ b/docs/topics/logging.txt @@ -164,10 +164,9 @@ is a parent of the ``project.interesting`` logger. Why is the hierarchy important? Well, because loggers can be set to *propagate* their logging calls to their parents. In this way, you can define a single set of handlers at the root of a logger tree, and -capture all logging calls in the subtree of loggers. A logging handler -defined in the ``project`` namespace will catch all logging messages -issued on the ``project.interesting`` and -``project.interesting.stuff`` loggers. +capture all logging calls in the subtree of loggers. A logger defined +in the ``project`` namespace will catch all logging messages issued on +the ``project.interesting`` and ``project.interesting.stuff`` loggers. This propagation can be controlled on a per-logger basis. If you don't want a particular logger to propagate to its parents, you