Thank you.  I should have been more clear about what I meant.

This this condition was introduced in r38631 by Vinay Sajip having the log
message "Added optional encoding argument to file handlers." I can't easily
see why this piece of code is necessary, which absolutely doesn't mean it
isn't.

I'm going to suggest some cases where other modes may be appropriate for
loggers. This is a little open-ended and devoid of solution-orientation, but I
don't know the rationale well enough to suggest alternatives.

We do know that 'r' (read-only logger) and 'w' (logger rarely rolls over for
traditional maxBytes values, but might -- this mode also makes relatively
little sense with ``logger.FileHandler``) make little sense here. I'm not
aware of a binary log format, so 'b' might make little sense as well. What
about 'U' and '+'?

For instance, the W3C Extended Log File Format draft uses headers at the
beginning of a log file. Ideally, knowing whether to write headers to the file
is done by using the ``handler.stream`` to determine whether the file is
empty. It may be debatable whether supporting such formats is the purpose of
handlers. If not, it's at the cost of writing new libraries that handle
logging for those formats.

I will never be able to exhaustively list use cases. If these modes are safe,
shouldn't the developer decide makes sense, as long as it doesn't break the
functionality of the logger?

I don't know whether it's generally approrpiate to add people to the nosy
list. I apologise, Vinay, if that's not common practice.