[issue9576] logging.addLevelName in file-based configurations

Vinay Sajip added the comment: 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

[issue9576] logging.addLevelName in file-based configurations

Tarek Ziadé added the comment: 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

[issue9576] logging.addLevelName in file-based configurations

Vinay Sajip added the comment: No feedback on this after two weeks, so closing. -- status: pending -> closed ___ Python tracker ___ __

[issue9576] logging.addLevelName in file-based configurations

Vinay Sajip added the comment: 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 loggi

[issue9576] logging.addLevelName in file-based configurations

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9576] logging.addLevelName in file-based configurations

New submission from Tarek Ziadé : 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 -- assignee: vinay.sajip components: Library (L