This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author grahamd
Recipients amaury.forgeotdarc, andyharrington, barry, eric.araujo, erob, flox, georg.brandl, ggenellina, grahamd, oopos, pebbe, pitrou, quentel, r.david.murray, tcourbon, tobias, v+python, vstinner
Date 2011-01-14.06:08:07
SpamBayes Score 1.71887e-06
Marked as misclassified No
Message-id <>
FWIW, keep in mind that cgi.FieldStorage is also quite often used in WSGI scripts in arbitrary WSGI servers which have got nothing to do with CGI. Having cgi.FieldStorage muck around with stdout/stderr under WSGI, even where using a CGI/WSGI bridge, would potentially be a bad thing to do, especially in embedded systems like mod_wsgi where sys.stdout and sys.stderr are replaced with file like objects that map onto Apache error logging. Even in non embedded systems, you could very well screw up any application logging done via stdout/stderr and break the application.

So, the default or common code paths should never play with sys.stdout or sys.stderr. It is already a PITA that the implementation falls back to using sys.argv when QUERY_STRING isn't defined which also could produce strange results under a WSGI server. In other words, please don't go adding any more code which makes the wrong assumption that this is only used in CGI scripts.
Date User Action Args
2011-01-14 06:08:11grahamdsetrecipients: + grahamd, barry, georg.brandl, amaury.forgeotdarc, ggenellina, pitrou, vstinner, andyharrington, eric.araujo, v+python, r.david.murray, oopos, tcourbon, tobias, flox, pebbe, quentel, erob
2011-01-14 06:08:11grahamdsetmessageid: <>
2011-01-14 06:08:08grahamdlinkissue4953 messages
2011-01-14 06:08:07grahamdcreate