[Web-SIG] Returned application object and fileno.
py-web-sig at xhaus.com
Wed Sep 1 20:19:27 CEST 2004
[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
> 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!
More information about the Web-SIG