[Web-SIG] Re: Re: The rewritten WSGI pre-PEP
Phillip J. Eby
pje at telecommunity.com
Wed Aug 11 20:30:49 CEST 2004
At 07:15 PM 8/11/04 +0200, Fredrik Lundh wrote:
>Phillip J. Eby wrote:
> >>- 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"
>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,
More information about the Web-SIG