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

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.

No feedback on this after two weeks, so closing.

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.

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.