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