classification
Title: logging.addLevelName in file-based configurations
Type: Stage:
Components: Library (Lib) Versions: Python 3.2
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: vinay.sajip Nosy List: eric.araujo, tarek, vinay.sajip
Priority: normal Keywords:

Created on 2010-08-12 15:44 by tarek, last changed 2010-09-03 10:10 by vinay.sajip. This issue is now closed.

Messages (5)
msg113686 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2010-08-12 15:44
It's not possible to use a custom level in a file-based configuration unless you programatically call logging.addLevelName('LEVEL', VALUE)

It would be nice to be able to declare new levels in config files
msg114365 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2010-08-19 15:06
While custom levels are supported for the rare cases where they're needed, they're not really encouraged. For example, if third-party libraries each set their own custom logging levels, it would be a headache to integrate them into an application's overall logging scheme.

So I'm not in favour of making it easier to define custom levels via configuration - it's not (meant to be) a common use case.
msg115425 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2010-09-03 09:14
No feedback on this after two weeks, so closing.
msg115427 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2010-09-03 09:32
You set it to "won't fix", that's why I didn't give you any feedback.

In general, if you provides features programatically *and* via configuration, it makes sense to provide the whole set on both sides.

IOW, if you don't want a feature to be used by third-party apps, it should not be exposed at all.
msg115431 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2010-09-03 10:10
I set to "pending" and "wontfix" to indicate what my proposed resolution was, and to await feedback - sorry for the misunderstanding.

The custom levels feature is not intended to be used casually (as it will cause unpredictable behaviour when used differently in different third-party libraries), but there are less common application-level scenarios (where logging interoperability is less of an issue) where custom levels might be needed - which is why they are provided.

It seems acceptable to me to have different conventions for third-party code and application code. For example, NullHandler is recommended for use with third-party libraries but is not especially useful for applications.

Configuration is not intended to *completely* cover the programmatic API - just to make it easier to do the most commonly-required things.
History
Date User Action Args
2010-09-03 10:10:05vinay.sajipsetmessages: + msg115431
2010-09-03 09:32:41tareksetmessages: + msg115427
2010-09-03 09:14:03vinay.sajipsetstatus: pending -> closed

messages: + msg115425
2010-08-19 15:06:09vinay.sajipsetstatus: open -> pending
resolution: wont fix
messages: + msg114365
2010-08-12 15:52:48eric.araujosetnosy: + eric.araujo
2010-08-12 15:44:52tarekcreate