[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>
This commit is contained in:
Miss Islington (bot) 2023-01-27 11:12:18 -08:00 committed by GitHub
parent 1016909a6d
commit 88a1e6db0f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 0 deletions

View File

@ -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