[Web-SIG] Re: Re: The rewritten WSGI pre-PEP

[Phillip J. Eby]

At 07:15 PM 8/11/04 +0200, Fredrik Lundh wrote:
>Phillip J. Eby wrote:
>
> >>Advantages:
> >>- contexts can (probably) be reused
> >>- attributes can be lazily initialized (via properties or getattr hooks)
> >>- the user code looks nicer
> >>- future safe: more attributes and methods can be added to the context
> >>   object in future revisions of this specification, without changing the
> >>   function signatures
> >
> > All of these advantages also apply to an object supplied in the 
> dictionary, i.e.:
> >
> >     environ['some_server.context'] = context_object
>
>that's obviously not true: environment dictionaries cannot be reused,
>environment items cannot be lazily initialized (since you require apps
>to use a PyDict), and the code using WSGI variables has to use dict
>access syntax (x["y"]) instead of standard attribute access (x.y).

I meant that a server-specific 'context_object' can have all those 
advantages, not that the dictionary would.  In other words, I was 
suggesting that WSGI extensions could make use of all of these things, but 
I'd prefer that the core WSGI variables weren't presented that way.

Given that all the WSGI-defined keys are strings or booleans, except for 
'input' and 'errors', I don't see the advantage of lazy initialization for 
the spec-defined values.  I will agree that user code would look nicer as 
attributes, but there are other ways to accomplish that, such as using 
constants for keys, e.g. 'environ[INPUT]', or functions 'input_of(environ)'.

As for future safety, you can add as many framework- or server-specific 
keys, as long as you follow the naming convention.  And those entries can 
be objects of whatever nature is desired.

So really, the only thing that an object *adds* is a '.' syntax.  But, this 
syntax doesn't easily allow for namespaces: if server A and server B both 
define a 'foo' method, but with different signatures, how can an 
application tell what kind of 'foo' it is?  At least with a dictionary, the 
application object can look for 'server_A.foo' and 'server_B.foo' keys.

Finally, although I do want it to be simple on both the server and app 
sides, please remember that this is primarily intended to be a 
server-to-framework protocol, not an API for writing applications.  It's 
expected that normally the only code dealing directly with the WSGI 
'environ' is either framework code, "middleware", or a server.


> > The advantage is simplicity of implementation.  It's possible to write 
> middleware (application
> > that's also a server) without creating any new classes.
>
>so "def a(b)" is easy to write, but "class a" is hard to write?

No, it's that one can write code to transform the dictionary in-place, 
while supplying an altered context object will require not just an extra 
class, but potentially error-prone code to copy attributes and delegate 
methods to the previous context object.  That is, unless the spec requires 
that the context object allow arbitrary attributes to be set, or provides 
some extension dictionary, there's no way for a "middleware" component to 
add new behaviors.  Whereas, under the present spec, it's just 
'environ[somekey]=value', and pass the call on to the next "application" 
object.


>you're obviously not interested in feedback from experienced Python
>programmers.  I'm sorry I wasted everybody's time.

Huh?  I thought we were just getting started.  Ian argued with me for weeks 
to get a lot of the stuff in this draft that he wanted, so I'm not closed 
to feedback, just thickheaded.  :)  I'm also prone to not communicating all 
of my assumptions/conclusions about a design, because I think they're 
"obvious".  So, feedback like yours forces me to elaborate on them, and if 
you can get me to understand your actual use case I'll try to incorporate 
it.  If it means redoing the whole spec, so be it -- if you search for my 
first posting of the spec last December, you'll notice that this version is 
almost *nothing* like the original, which had objects and methods galore, 
by comparison.