Colored HTTP status codes
HARRY POTTRER
this ticket:
http://code.djangoproject.com/ticket/6385
It seemed like a pretty cool idea, and I hoped it would get to be
added to the 1.2 release. Then I saw it was created over 2 years ago.
I applied the patch to my cope of 1.1, and it works perfectly. I've
been using it for 2 days and have had no problems.
What can I do to get this added to 1.2? (or any release for that
matter.) I have some free time, and a weird desire to make this part
of Django. I'm not familiar on how the whole process works. What do I
need to do?
Russell Keith-Magee
Well, you've done the first step - bringing the ticket to our
attention and offering to advocate on its behalf :-)
I've put some notes on the ticket. If you can address those issues in
a satisfactory way, I'll see about getting this into trunk.
Yours,
Russ Magee %-)
Karen Tracey
Note there's also requesting 7679 this. Malcolm was -1 on it due to colors not working well for everyone, and the patch was updated to use a setting. Not sure yet another setting is the best idea. At any rate one or the other of these should likely be closed as dupe by whoever takes on looking into this (not sure why one hasn't already been closed, someone already noted the overlap in 7679).
Karen
Russell Keith-Magee
Thanks for the heads up on the dupe - I've closed #6385.
I hadn't considered the colorblindness issue. It's a valid point, but
I don't think we should throw out the baby with the bathwater. For
those without color vision issues, colored output can be very useful.
The choice of colors (avoiding red/blue on black, or yellow on white)
is also a reasonable concern, and one that we don't address at
present.
However, the two issues are orthogonal. We already use color, so the
decision to disable/customize colorization is independent of the
decision to add colorization to runserver. I've opened #12112 to track
the orthogonal problem of controlling colorization.
I'm not convinced that a single setting is the right approach for
this. It almost seems like this is something that we should be using
environment variables or a dot file (e.g., a .djangorc with system
wide Django settings) - although this introduces a dependency on the
environment. I'm open to other suggestions.
Yours,
Russ Magee %-)
David De La Harpe Golden
> I'm not convinced that a single setting is the right approach for
> this. It almost seems like this is something that we should be using
> environment variables or a dot file (e.g., a .djangorc with system
> wide Django settings) - although this introduces a dependency on the
> environment. I'm open to other suggestions.
>
I was going to suggest that people who don't like color at all for one
reason or another could do 'export TERM=xterm-mono', but turns out that
doesn't seem to work for the django ./manage.py case* (separate issue
to configuring precise colors used in different situations, which might
be done through a DJANGO_COLORS env var akin to gnu ls's LS_COLORS,
or by some other means).
* It looks like django.utils.termcolors fires out ansi escapes and
hopes rather than using a terminal control abstraction layer
http://docs.python.org/library/curses.html
- note that you can use part of the python curses module just to access
the lowlevel terminfo functions (man terminfo), it's not just for
fullscreen mode curses applications - see also e.g.
http://nadiana.com/python-curses-terminal-controller
I'm on the clock and can't write a real patch, sorry, and I know
terminals can seem a bit arcane, but e.g. try the following under
TERM=xterm-256color vs. TERM=xterm-mono
#!/usr/bin/python
import curses # might want to fallback if unavailable
curses.setupterm()
setaf = curses.tigetstr('setaf')
if setaf:
magenta = curses.tparm(setaf, curses.COLOR_MAGENTA)
print magenta + "MAGENTA ALERT"
else:
print "MONO ALERT"