[Web-SIG] Questions/suggestions on 'wsgi.file_wrapper'
Phillip J. Eby
pje at telecommunity.com
Thu Dec 22 04:53:10 CET 2005
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
>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
More information about the Web-SIG