Add a method to list the current named logging levels

Chris Angelico rosuav at gmail.com
Wed Mar 30 12:39:33 EDT 2022


On Thu, 31 Mar 2022 at 03:33, Edward Spencer <tedpfspencer at gmail.com> wrote:
>
> 在 2022年3月30日星期三 UTC+1 16:38:26,<Barry> 写道:
> > > On 30 Mar 2022, at 16:11, Edward Spencer <tedpfs... at gmail.com> wrote:
> > >
> > > 在 2021年9月3日星期五 UTC+1 18:50:51,<Barry> 写道:
> > >>>> On 2 Sep 2021, at 23:38, Dieter Maurer <die... at handshake.de> wrote:
> > >>>
> > >>> Edward Spencer wrote at 2021-9-2 10:02 -0700:
> > >>>> Sometimes I like to pass the logging level up to the command line params so my user can specific what level of logging they want. However there is no easy method for pulling the named logging level names.
> > >>>>
> > >>>> Looking into the code, it would actually be incredibly easy to implement;
> > >>>>
> > >>>> in `logging.__init__.py`;
> > >>>>
> > >>>> def listLevelNames():
> > >>>> return _nameToLevel.keys()
> > >>>>
> > >>>> You could obviously add some other features, like listing only the defaults, sorted by numerical level or alphabetically, etc. But really this basic implementation would be enough to expose the internal variables which shouldn't be accessed because they change (and in fact, between python 2 and 3, they did).
> > >>>>
> > >>>> Any thoughts?
> > >>>
> > >>> Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING",
> > >>> "ERROR" and "CRITICAL".
> > >>> No need to provide a special function listing those levels.
> > >> I add my own levels, but then I know I did it.
> > >>
> > >> Barry
> > >>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Dieter
> > >>> --
> > >>> https://mail.python.org/mailman/listinfo/python-list
> > >>>
> > >
> > > Yes, the names are already well defined. But every software project anyone has that needs to use logging then has to define that list, which is a waste of time since they're already defined inside the logging repo. But no-one can access them unless they use protected variables. If it's a case of not wanting users to be able to modify the defaults, then just define that list of log levels as a tuple. Hiding it is unnecessary.
> > Is logging.getLevelNamesMapping() what you are looking for?
> >
> > Barry
> >
> >
> > > --
> > > https://mail.python.org/mailman/listinfo/python-list
>
> Hi Barry,
>
> What version for python / logging are you seeing that method in? I don't appear to be able to find it.
> I vaguely remember seeing something similar to it though, did it return a dict of {<str name>: <int level>} only or did it also include the reverse of int to str?
>

New in 3.11:

https://docs.python.org/3.11/library/logging.html#logging.getLevelNamesMapping

I'd say it's reasonable to use this, and then to backport it to older
versions by monkeypatching it in (by referencing the internal). You
potentially might have issues with other Python implementations, but
I'm pretty sure CPython has logging._nameToLevel with the same
semantics for quite a while.

ChrisA


More information about the Python-list mailing list