[Web-SIG] PEP 444 (aka Web3)

[Randy Syring]

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