[Web-SIG] RE: Comments/stylistic ideas regarding WSGI

[Phillip J. Eby]

At 10:32 AM 8/23/04 -0400, angryhicKclown at netscape.net wrote:
>I agree, however "a callable that is passed a callable which returns a 
>callable" could be mind-bending for some people.

As I said, I've done some work on that.  When the next draft comes out, if 
you can provide diffs of what you'd like it to say in those spots, it'll be 
helpful.


>Not neccessarily. They could extend something like this:
>
>class Gateway(object):
>     def __init__(self, parent=None):
>         self.parent = parent
>     def __getattribute__(self, key):
>         try:
>             return object.__getattribute__(self, key)
>         except AttributeError:
>             if self.parent != None:
>                 return getattr(self.parent, key)
>             else:
>                 raise
>     def write(self, data):
>         raise NotImplementedError
>     # ... more standard API functions here
>
>and instantiate it with the gateway they were passed from the caller.

And all of that code is pure "excise"...  a tax on the implementor that 
doesn't provide *them* with any benefit.  It's what the Zope folks call a 
"dead chicken": boilerplate code that everybody has to use, but nobody 
understands, copied mindlessly from one implementation to another, subject 
to subtle bugs that then will only be fixed in some of the implementations 
and not in others.


> >>>Finally, I think the most important reason this change should be
> >>implemented is because it allows the interface to be easily upgraded
> >>without breaking compatibility with older versions.
> >
> >Actually, the current interface includes *numerous* routes for extension,
> >including additional 'wsgi.' keys, and keyword arguments to callables.
> >
>
>I don't see why this can't be solved with OOP.

Because the point of OOP is to encapsulate functions into one object; WSGI 
wants the functions to be as separate as possible so middleware can 
selectively replace functions and delegate to the old ones.

Thus, OOP does not "solve" anything here; it introduces more problems.  I'm 
ordinarily a very OOPish person, but this is one of those cases where it is 
the exact opposite of a solution.



>Fair enough, however I think we're trying to solve a problem (extensions) 
>which has already been solved by inheritance.

No, the appropriate solution is the "Chain Of Responsibility" pattern, if 
you're familiar with the GOF patterns.  It's just that since Python 
functions are first-class objects, it's trivial to implement a Chain Of 
Responsibility with functions, rather than creating several objects to each 
house one function.