> I think we should acknowledge that people often have difficulties
> with the rather simple functionalities of the logging module,
> not only the advanced ones.

Perhaps some people do have difficulties, but that's always going to be the case no matter what you do. A cookbook should explore different things, both simple and less simple.

> But how is that necessary for the use case? Your LoggerAdapter-
> derived class could take the "existing class" as a constructor
> parameter (*), then inject the required info in its overriden
> process() method.

If you can adapt an existing class to look sufficiently like a dict, that's all you need to do - there's no need to subclass LoggerAdapter and override process(). There might be cases where that's the easier option.

It's surprising how resistant people can be to subclassing and overriding. For example, for issue #18345 which you raised (which I haven't yet addressed as you said it was low-priority), one straightforward approach would be to subclass the relevant FileHandler classes.

> If I had trusted your doc blindly, I would have thought it necessary
> to go through the "complicated scheme"

It depends on how carefully you read it - I don't think it's *actually* misleading, and I quoted in my earlier response the sentence, which comes before the example, which says that overriding process() is what you'd normally do.

What about my suggestion about a separate section for the example, to make it clearer that it's just another approach which might be more suitable in some scenarios?