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.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
