[Web-SIG] Returned application object and fileno.

[Alan Kennedy]

Phillip,

[Phillip J. Eby]
 > So here's the resolution: I will slightly expand the section on
 > supporting older versions of Python, to explicitly allow a 2.1 server to
 > "forward-compatibly" check for 2.2 idioms such as returning a file 
object.
 >
 > I'd prefer not to do that, but not because I dislike the approach.
 > We're in "violent agreement" on what *your* server should do about this,
 > and I encourage you to implement it.  Our disagreement (as I understand
 > it) is that:
 >
 > 1. I think this is a "server-specific extension" that's outside the
 > spec's scope to rule on the validity of, and
 >
 > 2. I don't think that requiring others to do what your code will be
 > doing is a good idea, because they don't *need* to, unless they're
 > trying to run 2.2 code on a 2.1 Python, which should *definitely* not be
 > a requirement of the spec.

That solution works for me.

Although it may seem that we're in disagreement, I like to see that as a 
necessary part of moving forward :-) Possibly the reason why our points 
are slipping by each other somewhat is because you're making technical 
arguments and I'm making a primarily community/social argument: 
supporting the most up-to-date jython available (which is sadly 
out-of-date wrt cpython).

And I've got to say you've got a much better and cleaner handle on the 
technics than I: I'm just a simple implementer who wants to make his 
framework as useful as possible to as wide an audience as possible.

Just a last few points

1. It was never my intention to force complication of other people's 
frameworks, but I see now that that would be unavoidable if returning a 
file object was a part of the spec, and that would be a bad thing.

2. This whole problem *will* finally go away when jython 2.(2|3|4) 
appears (which I believe it will, though to do this properly will 
require Sun to open their chequebook). If I had the time or resources, 
I'd be putting all my efforts into getting jython 2.2 out the door. But 
I don't have that time or resource, so I'm falling back to doing the 
best that I can with what's available. And jython 2.1 is *rock-solid*, 
and in use all over the place: people trust it.

3. Your solution allows me to address the most common case that I 
believe would cause problems: that of framework authors returning a 
file-object (without realising that cpython 2.2+ was creating an 
iterator for them behind the scenes). I think this is going to be a very 
common design paradigm for WSGI middleware.

4. I'll be doing my level best to get all python code to run under 
modjy, regardless of the version it was written for. There might be a 
lot of frantic paddling going on underneath the surface, but above the 
waterline hopefully everything will be calm and serene .....

Thanks again for this initiative: I believe that WSGI is *definitely* 
the future for python web servers. Great job!

Kind regards,

Alan.