It’s been suggested that a getChildren() method be added to logging.Logger to facilitate navigating the hierarchy. I think this is a reasonable thing to add.
I’d aim to implement the method, to be documented as follows:
Returns a set of loggers which are immediate children of this logger. So for example logging.getLogger().getChildren() might return a set containing loggers named foo and bar, but a logger named foo.bar wouldn’t be included in the set. Likewise, logging.getLogger('foo').getChildren() might return a set including a logger named foo.bar, but it wouldn’t include one named foo.bar.baz.
Sounds fine to me. I’m sure it can be misused, but so can everything else
ISTR a discussion (years ago) about the naming convention of the logging module, and I think one of the options[1] was to leave the camelCase names there, but add anything new with snake_case conventions. This might be the first time it’s come up since then, so might be worth doing a quick search to see if it shows up.
I don’t remember if this was selected or only proposed. ↩︎
Well this is what the previous discussion was about Just remembered that it happened, and all points of view were argued out already, so if it can be found (and it applies to logging, because Eric might be right) it could save repeating the discussion.
Well if all points of view were argued out … just a bikeshed discussion, then? It doesn’t seem like it’s worth the time digging for it. I’ve already prepared the PR.
Spent a bit of time searching and it’s not that obvious, so I guess go ahead with local consistency and if anyone wants to make a fuss then tell them to go and search harder than I did
