Ian Bicking: the old part of his blog


Folks, the place for discussing the PEP or proposing changes is the Web-SIG mailing list.

But as long as I'm here, I'll answer the question about "single-threaded", by quoting the PEP:

"""so that applications or frameworks that are not thread-safe may still be used with that server."""

Anyway, "shoulds" are recommendations, not requirements. A server can fail to provide this facility and still be considered conforming.

As for the examples "that are 'Much the same thing'", I agree that it should be rephrased to say that the two examples produce the same output, but are implemented differently, using a variety of WSGI features.

As for the looking over by other persons, I've previously asked for diffs/patches proposing rephrasings; only one person has actually given me any thus far, although Ian has at least also provided suggestions in in-line replies. This thing is over 1000 lines long now, and it's getting more and more difficult to find stuff when people say, "oh the stuff about X and Y was confusing", especially if they don't propose an alternative phrasing!

Anyway, I've submitted an updated draft to the PEPs editor, so it will be in Python CVS soon, which will make it easier to make and use patches.

Finally, I should mention that at this stage, the benefits of WSGI are primarily for web *framework* authors, and web *server* authors, not web *application* authors. This is *not* an application API, it's a framework-to-server glue API. It doesn't compete with any existing framework APIs.

It does, however, form a basis for future web APIs to be "plug-and-play" and "mix-and-match". But that day is still a ways off, and we won't reach it if framework and server authors don't implement this first stage.
Comment on WSGI Sample Apps and Middleware
by Phillip J. Eby