> 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.

Actually, I believe it is reasonable to intercept sys.stderr, even with logging in use, because you might be testing that logging actually works in a common scenario (use of StreamHandler in the default configuration). To do that, you would need to capture sys.stderr and check that its contents contain logged messages. For example, the Python test suite contains specific tests which intercept (and restore) sys.stderr, for this very purpose.

If one is careful to follow the sequence of events I mentioned in my last response, it should be safe to intercept sys.stderr. You only have to remember that if you have passed it to logging to use for I/O, logging may try to use it at times you don't expect (e.g. because of logging by third-party code). Just remove it from logging before you close it, and all will be well. This, of course, applies to any stream you pass to logging - not just sys.stderr or a replacement for it like a StringIO.

Using sys.__stderr__ is of course doable right now by your code; as you are the first one to mention this as desirable, I think it quite likely that people are working with the existing default without any problems. So it's unlikely that this default will change (as it doesn't need to - you can be explicit about the stream you want to use). If there is a lot of adverse feedback about the default (unlikely, since it's been there ever since logging was added to Python - about 10 years ago) then I will of course reconsider.