[Web-SIG] Returned application object and fileno.

[Alan Kennedy]

[Phillip J. Eby]
 > Does that make sense?

Phillip, sorry to be such a PITA, but no, it doesn't.

[Phillip J. Eby]
 >>> 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.

[Alan Kennedy]
 >> But that is explicitly forbidden

[Phillip J. Eby]
 > I've changed the spec now to allow authors to define a platform-specific
 > special method name for this purpose.

But there is no special method name or attribute on file-like objects 
that I can look for: file methods such as read() are the only options. 
Jython file objects have an identical interface to cpython file objects, 
except that they don't have fileno() methods.

Though I suppose could check the class of the returned object, e.g.

if isinstance(app_return, types.FileType):
   # Attempt high-performance stuff

[Alan Kennedy]
 >> 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.

[Phillip J. Eby]
 > 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.

A couple of points to make here

1. I see nothing 2.2 specific in my above code sample: it works on all 
pythons. I don't see what differs between 2.1 vs. 2.2 in this case.

2. The spec, as is, explicitly permits authors of cpython applications 
to return file-like objects, due to the cpython-specific special case 
"your application object may have a fileno()". Of course, most 
application authors won't know that the reason why their file return is 
succeeding is because the file object has a fileno() method, and then 
wonder why their app doesn't work on jython.

 > 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.

Sorry, I'm confused: what 2.2 idioms do you mean?

 > 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.

Sorry, Phillip, I'm confused. I don't see that this has anything to do 
with 2.1 vs. 2.2: it's got to do with how to recognise the case where 
the application returns a file-like object, which can then be treated 
specially, e.g. for high-performance reasons.

I think we should explicitly allow return of a file-like object, and 
thus freedom to use the read() method, etc. That's the 
platform-independent way to solve this problem. Then each 
server/framework author can map that to a high-performance 
descriptor/stream/channel in whatever way is appropriate for their 
platform. Or not bother with high-performance, and just read() all the 
file contents and transmit that.

Is there a specific reason, perhaps relating to python 2.2, that you 
want to prevent appplication authors from returning files?

Regards,

Alan.