At 07:32 PM 12/21/2005 -0800, Mike Orr wrote: >Phillip J. Eby wrote: > > >At 11:25 AM 12/21/2005 -0500, Jim Fulton wrote: > > > > > > > >>Here are some questions and sugesstions on the 'wsgi.file_wrapper' > >>part of the WSGI API: > >> > >>1. Does this need to be optional? It seems that it would be > >> easy for any server to provide this, it would be nice for > >> applications to be able to rely in it. > >> > >> > > > >It's intentionally optional because its presence signifies that the server > >can do things *better* than the application, if and only if the object is a > >"real" operating system file or other "special" object. The only reason > >the spec requires only a "file-like" object rather than an object with a > >valid "fileno()" method, is because somebody wanted to support Jython > >objects wrapping Java sio(?) objects, for a Java equivalent of sendfile(). > > > > > >Allowing a file-like object like StringIO also allows the environment to >be pickled and sent to another process. This lets a Python web server >talk directly to a Python application server using WSGI, rather than >having to kludge through SCGI and then repackage it to WSGI. I don't >know of any web servers that do this yet but it would be a shame to lose >the capability. > >If we require a file object, the environment becomes non-pickleable >because you can't serialize an open file. SCGI uses passfd, which >somehow works, but not on Windows. If we require .fileno(), one could >have an object that quickly writes the content to a file and passes that >fileno, but I don't see what that gains.
I think perhaps you've confused the 'file_wrapper' API with the file-like objects in the environment. The discussion above is about 'file_wrapper' objects *returned* by the application, not the input/stderr objects in the environment. _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
