phep <patrice.pil...@teletopie.net> added the comment: These are the changeset details: changeset: 18337:c2a60de91d2c branch: legacy-trunk user: Guido van Rossum <gu...@python.org> date: Fri Jun 29 13:06:06 2001 +0000 summary: Solve SF bug #231249: cgi.py opens too many (temporary) files.
You're right that we might use environment variables or tempfile.tempdir to attain the same goal but this would impact _all_ of the code executed during request data parsing given the monolithic construction of FieldStorage. This implies that the context of every call to tempfile members would be impacted during this process. Presently this is not a problem at all, but this looks fragile for future developments. On the other hand: 1) this has the advantage of not changing FieldStorage interface, 2) this alleviates us of wondering if passing to FieldStorage constructor all of the arguments to NamedTemporaryFile is a possibility worth considering ;-). After pondering this for a while I think the simpler is the better and I propose to add documentation to inform the reader that changing the temp directory through os.environ of tempfile.tempdir might worth consideration. As for other use cases for changing the temp directory, I thought about letting the user choose the FS of its choice with regard to performance or security (crypted FS) or even having the temp files created in a directory with 700 permissions. Last, you're perfectly right about the None argument. I fiddled last night with setting an environment to deploy and test a patched Python (I had some problem to understand what happened when I encountered 6755). This now works and the patch does not introduced any regression. I still have to add unit tests (I only tested with my embryonic cgi script) and update the documentation before to send the patch. I should be able to do that in a few days at most. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9968> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com