LogFormatter: allow color support when sys.stderr.isatty() == False

[javabrett]

LogFormatter:

tornado/tornado/log.py

Line 81 in c447875

class LogFormatter(logging.Formatter):

... has very nice support for color logging via curses (or colorama).

My issue is with the test sys.stderr.isatty() in:

tornado/tornado/log.py

Lines 55 to 71 in c447875

	def _stderr_supports_color() -> bool:
	try:
	if hasattr(sys.stderr, "isatty") and sys.stderr.isatty():
	if curses:
	curses.setupterm()
	if curses.tigetnum("colors") > 0:
	return True
	elif colorama:
	if sys.stderr is getattr(
	colorama.initialise, "wrapped_stderr", object()
	):
	return True
	except Exception:
	# Very broad exception handling because it's always better to
	# fall back to non-colored logs than to break at startup.
	pass
	return False

The LogFormatter might be able to be attached to a handler which is not writing to stderr type stream, but to some other TTY-capable device, which I have in my case. The syserr TTY test prevents attaching the LogFormatter to such logger handler and having color support.

If I monkey-patch _stderr_supports_color() to lambda: True, and make sure I make a call to curses.setupterm(fd=...), passing the fd of my TTY-capable stream, then I can log with the color support from LogFormatter, which is nice.

Maybe the best fix is to change color: True to None, but default based on the detection above, or if set to True explicitly by the caller, honour that.

[bdarnell]

Yeah, making the color argument three-valued (with None meaning "auto") seems like the way to go. That'll require a little refactoring to split the detection part of _stderr_supports_color from the initialization part, but that seems like a good idea anyway.

Now that I'm rereading the curses docs, it looks like we should also be passing stderr's file descriptor to curses.setupterm (otherwise it may send terminal escape characters to the wrong stream if stderr and stdout have different destinations).