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

Fredrik Lundh fredrik at pythonware.com
Wed Aug 11 13:04:50 CEST 2004

Phillip J. Eby wrote:

> As always, your comments and feedback are appreciated.
>      def run_with_cgi(application):
>          environ = {}
>          envrion.update(os.environ)


>          environ['wsgi.input']        = sys.stdin
>          environ['wsgi.errors']       = sys.stderr
>          environ['wsgi.version']      = '1.0'
>          environ['wsgi.multithread']  = False
>          environ['wsgi.multiprocess'] = True

The answer's probably hidden somewhere in the mailing list archives, but why
do you mix WSGI variables with external CGI environment variables?

I'd prefer

     def application(context, environ, start_response)

where context is an object of a server-defined type, with attributes for
input, errors, etc:

            context = MyApplicationServerContext()
            context.input = sys.stdin
            context.errors = sys.stderr
            context.version = "1.0" (or (1, 0))

- 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

- one more argument; but if that's really a problem, why not make
  start_response a method of the context class?

        def application(context, environ):
            context.start(status, headers)

> The second parameter passed to the application object is itself a
> two-argument callable, used to begin the HTTP response and return
> a ``write()`` function.  The first parameter it takes is a "status"
> string, of the form ``"999 Message here"``, where ``999`` is replaced
> with the HTTP status code, and ``Message here`` is replaced with the
> appropriate message text.

To make life easier for users, you might wish to accept either an integer
status code (e.g. start(200, headers)) or a string.  In case a status code
is provided, the server can fill in a suitable string value (as per the HTTP

Except for those small nits, I'm totally +1 on this proposal.


More information about the Web-SIG mailing list