[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On 8/24/20 10:39 PM, Adam Hendry wrote:

In the spirit of CHB's recommendation, this is my proposal:

Would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib?

    - Use properties and magic methods instead of getter and setter methods     - Add flag tfor `sys.excepthook` to choose whether to route all unhandled exceptions to the root logger     - PEP8ify to make source code more readable and "pretty"     - Make module-level `getLogger()` a class singleton, as it's only to be used once (warrants further discussion; I don't know if this is unnecessary)     - Provide context managers for loggers to prevent race conditions (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants further discussion; I don't know if this is unnecessary)     - Enable iteration over all existing loggers by writing `__len__`s and `__getitems__` for logging  (warrants further discussion; I don't know if this is unnecessary)

Again, these are just my thoughts. Mike Miller is right in that the `logging` module is EXTREMELY intimidating to the new user. This keeps new users from logging, which (arguably) should be done as best practice.

On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry mailto:adam.grant.hendry@gmail.com> wrote:

Hello Everyone,

Uh-oh, I think you misunderstood me. I was trying to be funny. Raymond always does his "fist-slamming" thing in a funny way, so I was trying to emulate that. I'm not mad. This is my first feature request post.

The `logging` module works, so there's nothing that needs to be fixed. Believe me, I'm a content-over-form programmer every day of the week and twice on Sunday. We could make it more Pythonic though.

One feature I would like to have added though is a flag I can set to route all unhandled exceptions to the root logger. I need this for my production GUIs, for example, and I have to override `sys.excepthook()` to get this to work right now. Not a huge problem currently, but I think this would be a nice addition to the module.

Adam

One comment on getLogger(), my understanding is that this is NOT required to be called just once (but one common code style does), but it has a promise: Multiple calls to getLogger() with the same name will always return a reference to the same Logger object. Now it does have the slight weirditty that the string given is effectively a path into a hierarchy using dots. One strategy is to call it getLogger(__name__) in a file, and if you do that, it is more efficient to set a module level global to it so you don't need to keep calling it (but you can) Following CHB, you might introduce a module object logging.logger that you can use to access the loggers, but the fact that it isn't a flat dictionary makes some of the suggestion not quit as appropriate. -- Richard Damon