Graham Dumpleton wrote: >> As an avid use of "print" for debugging, this would bug me. I would >> prefer just avoiding the CGI case where stdout goes to the client, and >> otherwise saying that the server should try to put stdout output >> someplace where it can be read. But it could very well be a console, >> not necessarily a log file. Or the same log file as stderr, or... >> something. > > Although using 'print' is handy. The reason I was making sys.stdout > off limits and not just merging the output with sys.stderr, is that at > least one Python web framework hijacks sys.stdout for their own > purposes so that people can use 'print' to generate the actual content > of the response. The package that does this is web.py > (http://webpy.org/). Not sure if there are others which do this.
I don't know of any others. As a debugging tool I'm not as concerned, as if a web.py user used something I wrote I would have hopefully removed all prints -- if I hadn't, it would be a bug (not an uncommon bug, but a bug). And the web.py user just won't do this, because they'll instantly break their app. Paste also has something that will capture prints/sys.stdout and put it into the page that is served up (paste.debug.prints). That middleware strategy would probably work regardless of what the server does. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
