Thanks to Chris M. and Armin for moving forward with a PEP!
Armin Ronacher wrote:
Hi,
On 9/16/10 1:23 PM, Dirkjan Ochtman wrote:
I find the order of the application return arguments really annoying,
could it just be status, headers, body? Mirrors the actual structure
of the request, which is easier to remember IMO.
The motivation is that you can pass that to constructors of response
objects already in place.
response_tuple = response.get_response_tuple()
response = Response(*response_tuple)
chris.d...@gmail.com wrote:
On the other end of that same principle, I'm not sure I can see
much justification in (paraphrase) "let's make the return signature be
the same as the signature of some constructors at use out there
in the wild".
FWIW, I am with Dirkjan and Chris on this...the most logical ordering
for a response tuple is:
status, headers, body
Trying to conform the spec to existing frameworks doesn't seem like the
best approach in this case.
--------------------------------------
Randy Syring
Intelicom
502-644-4776
"Whether, then, you eat or drink or
whatever you do, do all to the glory
of God." 1 Cor 10:31
chris.d...@gmail.com wrote:
On Thu, 16 Sep 2010, jason kirtland wrote:
The 'pegboard' middleware composes a result out of an arbitrary graph
of WSGI apps, with one request visiting many applications. The graph
can be built at runtime in application code, so it would be very
difficult to report all of the '.app's applicable for a given environ
until after the request. Also, it is quite reasonable in practice to
have middleware both in front of such a composer and also in the
stacks of the apps it composes.
The general rule we can extract from this is that we don't want the spec
to limit what is possible for the sake of making fairly arbitrary things
that only some people (think they?) need and can be satisfied using
the more fundamental units already present in the design.
I can see that applying here, thus we don't want to enforce some kind of
"app" method or attribute as that could be costly for assembling
flexible groups of apps (in the same app).
On the other end of that same principle, I'm not sure I can see
much justification in (paraphrase) "let's make the return signature be
the same as the signature of some constructors at use out there
in the wild".
One of the best things about WSGI, that I hope does not get lost in
Web3 (thanks for moving things forward, by the way), is that in its
most basic use it is almost entirely about (simple) data structure
and (simple) data flow and not about methods, objects, magical
attributes and other flim flammery.
In other words it is good that the units are basic and fundamental.
_______________________________________________
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
