@vinay.sajip the problem is that many tools that don't do anything with logging module intercept sys.stdout and sys.stderr. Such tools typically aren't even aware of libraries they use (or test) using logging and much less about them registering StreamHandler using sys.stderr.

It's great that nowadays you don't always get ValueError at exit anymore. Now you only get them if the StreamHandler itself tries to use the stream after sys.stderr is restored and the intercepting stream closed. Typically this only happens in error situations so the problem isn't so severe.

IMHO nobody should ever register StreamHandler with sys.stderr because you cannot be sure has someone intercepted it or not. There's a strong convention that sys.__stderr__ should not be intercepted so using it is safe.

I strongly believe StreamHandler should be changed to use sys.__stderr__ by default. That shouldn't cause problems because a) if sys.stderr isn't intercepted sys.stderr is sys.__stderr__, and b) if sys.stderr is intercepted you most likely already have problems. I know stuff like this cannot be changed other than in major releases and there should perhaps even be a deprecation period. I also acknowledge that it might be too much work to be worth the effort. Mentioning this issue in the docs might be a good idea nevertheless.