Track implementation of logger hierarchy introspection as per

http://plumberjack.blogspot.co.uk/2012/04/introspecting-logger-hierarchy.html

Added Brandon to nosy list, as his logging_tree is what set the ball rolling on this one. Brandon, your comments on the patch would be very welcome.

Perhaps you should explain what the point of this is.

I think that's what the link in the first message does.  However, as I remember Bradon's talk, the short answer is: make it easy to discover (and therefore reason about) the hierarchy of logging objects that results from all the logging setup calls in an application.

Adding an entirely separate API for introspection strikes me as counter-productive — instead of merely having to maintain the logging API that you already maintain, you will additionally now have an entirely separate and second API that also has to be maintained forever.

Reading back over the current logging documentation, it looks like the problem is that the documentation only includes verbs — the methods that can be invoked — but not adjectives: the attributes that are attached to each logger, handler, and filter. This is contrary to modern Python APIs, which typically document their attributes and offer direct access to them; within the Standard Library, cf the threading.Thread object for one that has done a good job of moving into the modern world with directly-accessible attributes.

So my guess would be that you should discard the idea of a separate introspection API, and simply document that attributes of each logger, handler, and filter that today are already perfectly introspectable. Check out the logging_tree code if you want to make sure that you are “promoting” into document-hood all of the attributes that I needed in order to do my introspecting there.

Taking Brandon's advice re. creating a separate API.

However, note the reasons for not documenting all the attributes and hiding them behind functions: logging's design pre-dates properties (it's of Python 1.5.2 vintage) and implementation details should remain as hidden as they can be, given Python's essentially non-private nature (even though they are unlikely to change after all this time, you never know ...)