[Web-SIG] PEP 444 != WSGI 2.0

[Alice Bevan–McGregor]

On 2011-01-02 11:57:19 -0800, P.J. Eby said:
> FWIW, my lack of interest has been due to two factors.  First, 
> theoriginal 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 meas more of 
> the same, and put me off from investigating further.  (Thewhole idea of 
> having a WSGI 2 (IMO at least), was to get rid of cruft and fix bugs, 
> not to add new features.)

Interestingly, I see PEP 444 / WSGI 2 as the oppostie; 3333 fixes the 
major outstanding bugs that block Python 3 compatibility without 
improving anything else, 444 is an opportunity to shape the future by 
making previously optional things required (like HTTP/1.1 support) and 
adding features that individual framework authors have all implemented 
in incompatible ways (async).

> Reading the draft now (I had not done so previously), I would 
> suggestmaking your filters proposal available as a standalone module 
> (or anaddition to a future version of wsgiref.util), for anybody who 
> wantsthat feature, e.g. via:

The filtering API is marked as optional, with an example of using it as 
middleware.

> (Writing this implementation highlights one problem with the notionof 
> filters, though, and that's that egress filters can't trap anerror in 
> the application.)

Egress filters only run on successful (non-exceptional) resopnses; if 
you need to capture exceptions to return non-exceptional responses 
(e.g. debugging), you use middleware.  This is not a bug, it's a design 
feature.  :)

> 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 todo 
> without basically printing out both PEPs and doing a line-by-line 
> analysis.

I'll do so.

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

No, file_wrapper was missing because it's simply one thing I haven't 
gotten around to declaring in a point-by-point RFC manner yet.  :/

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

I've corrected my local copy and will push after reading some 
additional messages.

> * 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 bothways of 
> providing the same variable, or to delete the extended version when 
> modifying the environment.)

Agreed.

> * -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 beused.  
> (That is, the environ consists of bytes-in-unicode-form, rather than 
> true unicode strings.)

Does ISO-8859-1 not accomodate this for all but a small number of the 
environment variables in PEP 444?  (Specifically, variables refering to 
parts of the URL/URI.)  And for those variables decoded differently, 
there is an environment variable containing the encoding used.

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

In /theory/ you could write a PEP 444-compliant server specifically for 
versions of Python < 2.6, this is not likely to be done, however.

> * Where is the PARAMETERS variable defined in the CGI spec?  
> Whatservers actually support it?

It's defined in the HTTP spec by way of 
http://www.ietf.org/rfc/rfc2396.txt URI Syntax.  These values are 
there, they should be available.  (Specifically semi-colon separated 
parameters and hash-separated fragment.)

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

I will re-examine the currently published PEP 444.

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

In point of fact, I have been, but I need more in comment than "that 
won't work".

> 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 specthan they 
> can.  You don't have to make *your* proposal into *Graham's* spec, or 
> even the spec that Graham would have wanted youto make.  But you *do* 
> need to take Graham's *goals* into consideration.

Indeed.  I do try to understand the issues covered in a broader scope 
before writing; for example, I do consider the ability for new 
developers to get up and running without worrying about the example 
applications they are trying to use work in their version of Python; 
thus /allowing/ native strings to be used as response values on Python 
3.

Byte strings are still perferred, and may be more performant, but 
getting started becomes much easier.  This is just one of the points I 
happened to agree on.  ;)

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

There's a difference between /competition/ and /eliminating pointless, 
incompatible reimplementation/.  A -simple for the application 
developer- async specification will ensure portable, more easily 
tested, consistent solutions.

> So, I urge you to pay attention when Graham says something about 
> whatthe spec is lacking or how it's broken.

I certainly will; I just need to see concrete points against the 
technical merits of the rewritten PEP, not pointless arguing about the 
name of a draft document.  ;)

Thank you for your input!

	- Alice.