[Web-SIG] Returned application object and fileno.

[Phillip J. Eby]

At 02:40 PM 9/1/04 +0100, Alan Kennedy wrote:
>[Alan Kennedy]
>>>But we also need to consider what happens when the application returns, 
>>>for example, a StringIO.StringIO, or a gzip.GzipFile.
>
>[Phillip J. Eby]
>>No, we don't.  WSGI does not support that.  You must return an 
>>*iterable*.  As Andrew says, 'fileno()' was added to allow special-casing 
>>operating system file descriptors on platforms that have them, and have 
>>APIs like 'sendfile()' that can copy data directly from one descriptor to 
>>another.
>>If you would like to support special Java stuff, or CLR stuff, you can 
>>always have your server look for some other attribute name and support 
>>that as a platform-specific, optional extension for higher performance.
>
>But that is explicitly forbidden: "Finally, servers must not directly use 
>any other attributes of the iterable returned by the application. For 
>example, it[sic] the iterable is a file object, it may have a read() 
>method, but the server must not utilize it. Only attributes specified 
>here, or accessed via e.g. the PEP 234 iteration APIs are acceptable."

I've changed the spec now to allow authors to define a platform-specific 
special method name for this purpose.


>But I don't see any WSGI compliant way in jython that I can take a static 
>file object returned by a WSGI application and do anything with it at all.
>
>For example, if the application works like this, which I'd imagine is a 
>common expected usage pattern, then I can do nothing
>
>def app_object(environ, start_response):
>   start_response("200 OK", [ ('content-type', 'image/jpg') ])
>   return open("%s.jpg" % environ['PATH_INFO'], 'rb')
>
>This will work on cpython, of course, because of implicit fileno() method 
>on the (cpython) file object. But will fail on jython, which will confuse 
>the hell out of appliction authors.

If they want to support Python versions prior to 2.2, they can't return a 
file object.  The above code simply isn't portable to Python 2.1.

But, since your use case is, "try to allow 2.2 code to run anyway", it's 
also reasonable for you to hack in support for objects of type 'file' (and 
whatever type Jython uses for pipes) and pretend they're iterables.  You're 
specifically trying to support some 2.2 idioms rather than deal with 2.1 
limitations, so this is just another one for you.

Don't let the spec stop you from supporting your use case.  The problem is 
simply that your use case is outside the spec's scope, and I don't want to 
expand the spec's scope to make *everybody else* have to implement the 
extras you're implementing.  I don't want to force everybody else to try to 
support 2.2 features in a 2.1 Python.

Does that make sense?