[3.11] [doc] Add a section on logging handler configuration order. (GH-101380) (GH-101382)

Co-authored-by: Vinay Sajip <vinay_sajip@yahoo.co.uk>

1 files changed, 23 insertions, 0 deletions

diff --git a/Doc/library/logging.config.rst b/Doc/library/logging.config.rst
index 671f3c8..93e4529 100644
--- a/Doc/library/logging.config.rst
+++ b/Doc/library/logging.config.rst
@@ -564,6 +564,29 @@ attribute ``baz`` set to ``'bozz'``.
    configuration machinery, but set as attribute values as-is.
 
 
+.. _handler-config-dict-order:
+
+Handler configuration order
+"""""""""""""""""""""""""""
+
+Handlers are configured in alphabetical order of their keys, and a configured
+handler replaces the configuration dictionary in (a working copy of) the
+``handlers`` dictionary in the schema. If you use a construct such as
+``cfg://handlers.foo``, then initially ``handlers['foo']`` points to the
+configuration dictionary for the handler named ``foo``, and later (once that
+handler has been configured) it points to the configured handler instance.
+Thus, ``cfg://handlers.foo`` could resolve to either a dictionary or a handler
+instance. In general, it is wise to name handlers in a way such that dependent
+handlers are configured _after_ any handlers they depend on; that allows
+something like ``cfg://handlers.foo`` to be used in configuring a handler that
+depends on handler ``foo``. If that dependent handler were named ``bar``,
+problems would result, because the configuration of ``bar`` would be attempted
+before that of ``foo``, and ``foo`` would not yet have been configured.
+However, if the dependent handler were named ``foobar``, it would be configured
+after ``foo``, with the result that ``cfg://handlers.foo`` would resolve to
+configured handler ``foo``, and not its configuration dictionary.
+
+
 .. _logging-config-dict-externalobj:
 
 Access to external objects