A while ago I was debugging through code that uses the `logging` module, and I was looking at `Logger` objects and possibly other kinds of objects (maybe handlers? It was a while ago.)

I was frustrated because I was trying to figure out what a particular logger was, but typing `logger` in the shell just showed the opaque `<logging.Logger object at 0x0000000002293550>`. I would like to know the name of the logger without bothering to do `logger.name`.

I suggest that we do a run over the `logging` module and see which classes could have a helpful `__repr__` added to them. I might have time to do this, but first I want to know whether there is a general agreement that such a patch would be welcome.

See attached patch for proposed changes.

New changeset 6c304a2ca139 by Vinay Sajip in branch 'default':
Closes #27650: Implemented repr methods for logging objects.
https://hg.python.org/cpython/rev/6c304a2ca139

Vinay: Looks good to me. What do you think about adding tests?

If you want, I can implement them.

IMO it's not really worth adding tests for __repr__() - because no external code should depend on the exact representation of instances of these kinds of classes.

Okay, but consider that if there are no tests, this code will never be run during testing. Consider that if there's a bug in that code that causes an exception to be raised (unlikely, I know, but maybe from the call to getLevelName) it won't be discovered until a release of Python is made and some user runs it and sees an exception. Maybe someone in the future will want to add more code into the __repr__ and that code will raise an exception. Having tests that run these methods ensures this will be caught before release.

This hangs this test from celery: https://github.com/celery/celery/blob/master/t/unit/app/test_log.py#L72

It constructs a Logger with `.parent` to itself, making getEffectiveLevel loop forever. The code tries to raise an exception when such loops are detected, but its message contains the logger's repr which calls getEffectiveLevel.

This sounds like a Celery bug, so I don't propose to change anything in this area.