Show HN: Pump, a dead simple Pythonic abstraction of HTTP.

"What WSGI should have been."<p>Well, not at all. Pump is what werkzeug, webob, and other more friendly wrappers on WSGI already are. Basically pointless duplication of work, without understanding why WSGI can't be this simple.<p>One basic reason that WSGI can't be as simple as just returning a dictionary is that you don't necessarily want the entire body of your response pre-computed before starting to return data to the client. What about long running connections? What if you want to return the head of the response immediately, so the client can start pulling css and js while you compute the body of the response? What if you want to do chunked encoding to support long polling connections, or responses where you don't know the response size beforehand?<p>Pump is basically doing what lots of other things already do, except without quite understanding HTTP quite as well.

The Rack style API is nice for the simplicity. I &#60;3 it.<p>The Rack style api is NOT a great representation of the HTTP protocol. Specifically anything with a streaming or chunked response.<p>start_response/yield may not be the absolute best API for this, I haven't thought to much about that. But if you go look into what was done in Rails 3.1 for chunked responses you may realize it's not actually too great.

The point of WSGI is not to be a good abstraction of HTTP. As an app author, you aren't supposed to care. The advantage of WSGI is that it's standard, and everything uses it. That means you can use any web framework with any web server, and it will all Just Work.<p>When you write your own copy of WSGI to change how some words are spelled, you don't gain much, but you lose the whole WSGI community. This seems rather pointless to me.

It seems like the author here is comparing Pump to WSGI -- perhaps a better comparison is to Ian Bicking's WebOb (<a href="http://webob.org" rel="nofollow">http://webob.org</a>) or Armin Ronacher's Werkzeug (<a href="http://werkzeug.pocoo.org/" rel="nofollow">http://werkzeug.pocoo.org/</a>).<p>WSGI is a low-level protocol that provides a minimal interface to an HTTP Server ala CGI. It is purposefully not an application-level HTTP toolkit. For example, a WSGI component takes an input stream and returns an iterable which could yield output chunks... of perhaps in infinite data stream. These edge cases are sometimes very important and why the interface is designed as it is: inconvenient as it may be for simple apps.

One issue that I have with it is that there is no distinction between script name and path info. Obviously, you don't have to call them that, but not having a distinction between the two makes it impossible to serve two Pump apps on the same domain and dispatch between them.<p>Also, there's no clearly defined format for middleware added by keys - the included middleware just adds plain old keys as it pleases.<p>But more generally, I don't really see the purpose of this. WSGI is obviously not ideal (thanks to start_response and CGI environment variables), but it's also quite firmly in place in the Python world. Not to mention that it would take the Pump library quite a while to catch up to Werkzeug or WebOb in terms of having all the necessary HTTP primitives implemented. (Multipart parsing, anyone?) Unless the server makers get on board, Pump is pretty much just an added layer of complexity on top of WSGI. Instead of "server | WSGI | WSGI library | framework", you have "server | WSGI | Pump adapter | Pump library | frameworK".

I don't see any way to use Pump to stream data in (a very long POST) or stream data out (a very long body). While it is certainly "dead simple", claiming that it is "what WSGI should have been" is a serious stretch.

Rolling your own small web framework in some arbitrary language seems to be one of the easier ways to add "open source project author" to one's resume. Not that I'm knocking it. But after you've seen the wheel reinvented the Nth time, you get increasingly less impressed on N+1, N+2, etc.

by passing dicts you are removing what makes WSGI work so well: lazy loading, chunked responses, middleware (encoding, caching etc.) by decorating, iterators/generators etc.<p>your solution is going to be slower, more memory intensive and will not be able to be http 1.1 compatible. there is a reason why WSGI was designed the way it is

Here's another NoWSGI HTTP server library (Brubeck):<p><a href="http://news.ycombinator.com/item?id=2770866" rel="nofollow">http://news.ycombinator.com/item?id=2770866</a>

Looks useful, though I think any modern abstraction like this should come with at least the scaffolding for future support of websockets. (They are a bit in flux right now, but will ultimately be incredibly useful.)

This seems interesting but I'm not sure why. What are some use cases?

I never understand the mentality of modern wsgi/cgi design. Passing parameters using environ? Why not directly as a python request object?

It is ironic that they mention "don't have to reinvent the wheel" in that page.

As far as web frameworks go, wsgi is pretty low level already. If you want to do a framework, move to a narrow vertical, it might get more traction.

<a href="http://xkcd.com/927/" rel="nofollow">http://xkcd.com/927/</a> Seems relevant here...