Friðrik Már Jónsson <frid...@pyth.net> added the comment: 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. ---------- nosy: +vinay.sajip _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9512> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com