[Web-SIG] PEP 444 != WSGI 2.0

[P.J. Eby]

At 01:47 AM 1/2/2011 -0800, Alice Bevan­McGregor wrote:
>The only things that depress me in the slightest are the lack of 
>current discussion on the Web-SIG list (I did post a thread 
>announcing my rewrite and asking for input, but there were no takers)

FWIW, my lack of interest has been due to two factors.  First, the 
original version of PEP 444 before you worked on it was questionable 
in my book, due to the addition of new optional features (e.g. 
async), and second, when I saw your "filters" proposal, it struck me 
as more of the same, and put me off from investigating further.  (The 
whole idea of having a WSGI 2 (IMO at least), was to get rid of cruft 
and fix bugs, not to add new features.)

Reading the draft now (I had not done so previously), I would suggest 
making your filters proposal available as a standalone module (or an 
addition to a future version of wsgiref.util), for anybody who wants 
that feature, e.g. via:

   def filter_app(app, ingress=(), egress=()):
       def wrapped(environ):
           for f in ingress: f(environ)
           s, h, b = app(environ)
           for f in egress:
               s, h, b = f(environ, s, h, b)
           return s, h, b
       return wrapped

(Writing this implementation highlights one problem with the notion 
of filters, though, and that's that egress filters can't trap an 
error in the application.)

As far as the rest of the draft is concerned, in order to give 
*thorough* technical feedback, I'd need to first make sure that all 
of the important rules from 3333 are still present, which is hard to 
do without basically printing out both PEPs and doing a line-by-line analysis.

I notice that file_wrapper is missing, for example, but am not clear 
on the rationale for its removal.  Is it your intention that servers 
wishing to support file iteration should check for a fileno() directly?

There are a number of minor errors in the draft, such as saying that 
__iter__ must return a bytes instance (it should return an iterator 
yielding bytes instances) and __iter__ itself has broken markup.

On other matters:

* I remain a strong -1 on the .script_name and .path_info variables 
(one of which is named incorrectly in the draft), for reasons 
outlined here previously.  (Specifically, that environ redundancy is 
a train wreck for middleware, which must be written to support both 
ways of providing the same variable, or to delete the extended 
version when modifying the environment.)

* -1 on the key-specific encoding schemes for the various CGI 
variables' values -- for continuity of coding (not to mention 
simplicity) PEP 3333's approach to environ encodings should be 
used.  (That is, the environ consists of bytes-in-unicode-form, 
rather than true unicode strings.)

* +1 to requiring Python 2.6 -- standardizing on b'' notation makes 
good sense and improves forward-portability to Python 3.

* Where is the PARAMETERS variable defined in the CGI spec?  What 
servers actually support it?

* The language about empty vs. missing environment variables appears 
to have disappeared; without it, the spec is ambiguous.

Those are the issues I have identified on a first reading, without 
doing a full analysis.  However, in lieu of such an analysis, I would 
take Graham's word on whether or not your spec addresses the HTTP 
compliance/implementation issues found in previous WSGI specs.

If I may offer a recommendation from previous experience steering 
this PEP, I would say that just because other people know (say) HTTP 
better than you, doesn't mean that you can't still make a better spec 
than they can.  You don't have to make *your* proposal into 
*Graham's* spec, or even the spec that Graham would have wanted you 
to make.  But you *do* need to take Graham's *goals* into consideration.

During the original drafting of PEP 333, Ian proposed quite a lot of 
features that I shot down...  but I modified what I was doing so that 
Ian could still achieve his *goals* within the spec, without 
compromising my core vision for the spec (which was that it should be 
as close to trivial for server implementers as possible, and not 
expose any application API that might be perceived by framework 
developers as competition).

So, I urge you to pay attention when Graham says something about what 
the spec is lacking or how it's broken.  You don't have to fix it 
*his* way, but you do need to fix such that he can still get 
there.  WSGI really does need some fixes for chunking and streaming, 
and Graham absolutely has the expertise in that area, and I would 
100% defer to his judgment on whether some proposal of mine got it 
right in that area.

That doesn't mean I would just adopt whatever he proposed, though, if 
it didn't meet *my* goals.

That's the hart part of making a spec, but it's also the part that 
makes one great.