[Web-SIG] Returned application object and fileno.
Alan Kennedy
py-web-sig at xhaus.com
Wed Sep 1 16:50:52 CEST 2004
[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.
More information about the Web-SIG
mailing list