@@ -564,6 +564,29 @@ attribute ``baz`` set to ``'bozz'``.
564
564
configuration machinery, but set as attribute values as-is.
565
565
566
566
567
+ .. _handler-config-dict-order :
568
+
569
+ Handler configuration order
570
+ """""""""""""""""""""""""""
571
+
572
+ Handlers are configured in alphabetical order of their keys, and a configured
573
+ handler replaces the configuration dictionary in (a working copy of) the
574
+ ``handlers `` dictionary in the schema. If you use a construct such as
575
+ ``cfg://handlers.foo ``, then initially ``handlers['foo'] `` points to the
576
+ configuration dictionary for the handler named ``foo ``, and later (once that
577
+ handler has been configured) it points to the configured handler instance.
578
+ Thus, ``cfg://handlers.foo `` could resolve to either a dictionary or a handler
579
+ instance. In general, it is wise to name handlers in a way such that dependent
580
+ handlers are configured _after_ any handlers they depend on; that allows
581
+ something like ``cfg://handlers.foo `` to be used in configuring a handler that
582
+ depends on handler ``foo ``. If that dependent handler were named ``bar ``,
583
+ problems would result, because the configuration of ``bar `` would be attempted
584
+ before that of ``foo ``, and ``foo `` would not yet have been configured.
585
+ However, if the dependent handler were named ``foobar ``, it would be configured
586
+ after ``foo ``, with the result that ``cfg://handlers.foo `` would resolve to
587
+ configured handler ``foo ``, and not its configuration dictionary.
588
+
589
+
567
590
.. _logging-config-dict-externalobj :
568
591
569
592
Access to external objects
0 commit comments