re-posting: web.py, incomplete

_wolf wolfgang.lipp at gmail.com
Sat Mar 4 12:59:57 EST 2006


ok, that does it! th at nks a lot!

sorry first of all for my adding to the confusion when i jumped to
comment on that ``-u`` option thing---of course, **no -u option** means
**buffered**, positively, so there is buffering and buffering problems,
**with -u option** there is **no buffer**, so also no buffering
problems at that point. these add-option-to-switch-off things do get
confusing sometimes.

ok, so the ``#!/usr/local/bin/python -u`` does work. as noted on
http://www.imladris.com/Scripts/PythonForWindows.html: "Trying to run
python cgi scripts in the (default) buffered mode will either result in
a complete lack of return value from your cgi script (manifesting as a
blank html page) or a "premature end of script headers" error." funny
you don't get to see a lot of ``-u`` shebang lines these days tho. as
the document goes on to explain, there is a way to put ::

    SetEnv PYTHONUNBUFFERED 1

into your apache ``httpd.conf``. this works for me! great!

now, thinking about this problem it strikes me it has never bitten me
before, where it should have. is there something special about the way
web.py cgi apps work that make this thing pop up? also, in theory,
since apache itself (as of v1.3) does no buffering of cgi output, then
when apache calls a cgi process, and that process happily buffers at
its own descretion, and then finalizes and terminates, then should the
remaining buffer not be output and sent to apache---as happens with a
script run from the command line? you do get to see all the output in
that case, at long last upon process termination, right? i'm wondering.

_wolf




More information about the Python-list mailing list