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

Post by pyninja » Wed, Jul 27, 2011, 2:37 AM UTC

irahul wrote: post #9

teej wrote: post #4

Earlier quoted context omitted.

I believe the intent is to be Rack[1] for Python. The beauty of Rack is that I can build a new web framework, web server, or web app plugin and have it "just work" with the rest of the ecosystem. And because the Rack API is so simple, building to spec is easy. In the Ruby world if I want to use the awesome library Sass all I have to do is: gem install sass Because it functions as a Rack plugin it automatically works…

# WSGI def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield 'Hello World\n' # Rack app = proc do |env| [ 200, {'Content-Type' => 'text/plain'}, "a" ] end WSGI is the Rack for Python. In fact, WSGI predates Rack, and Rack is WSGI inspired.

    # Pump
    def app(request):
        return {
          "status": 200,
          "headers": {"content_type": "text/plain"},
          "body": "Hello World"}

Post by xioaqmajtt » Wed, Jul 27, 2011, 2:40 AM UTC

benatkin wrote: post #3

Here's another NoWSGI HTTP server library (Brubeck): http://news.ycombinator.com/item?id=2770866

Post by irahul » Wed, Jul 27, 2011, 2:42 AM UTC

pyninja wrote: post #5

pbreit wrote: post #2

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

Building web apps! Basically, it's meant to be a replacement for WSGI. In my view, the problems with WSGI are that it has an unpythonic API (see: start_response and environ), and that it doesn't come with standard middleware that all frameworks use, so they all end up reinventing the wheel. Pump does a better job of abstracting out the details of HTTP, and also comes with a lot of useful middleware. This makes it rea…

Post by bobbyi » Wed, Jul 27, 2011, 2:45 AM UTC

irahul wrote: post #9

teej wrote: post #4

Earlier quoted context omitted.

I believe the intent is to be Rack[1] for Python. The beauty of Rack is that I can build a new web framework, web server, or web app plugin and have it "just work" with the rest of the ecosystem. And because the Rack API is so simple, building to spec is easy. In the Ruby world if I want to use the awesome library Sass all I have to do is: gem install sass Because it functions as a Rack plugin it automatically works…

# WSGI def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield 'Hello World\n' # Rack app = proc do |env| [ 200, {'Content-Type' => 'text/plain'}, "a" ] end WSGI is the Rack for Python. In fact, WSGI predates Rack, and Rack is WSGI inspired.

    public class App extends HttpServlet {
      public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/plain");
        response.getWriter().println("Hello world");
      }
    }

Post by irahul » Wed, Jul 27, 2011, 2:48 AM UTC

bobbyi wrote: post #17

irahul wrote: post #9

Earlier quoted context omitted.

# WSGI def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield 'Hello World\n' # Rack app = proc do |env| [ 200, {'Content-Type' => 'text/plain'}, "a" ] end WSGI is the Rack for Python. In fact, WSGI predates Rack, and Rack is WSGI inspired.

They are both predated by: public class App extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); response.getWriter().println("Hello world"); } }

    # hello.cgi
    print "Hello World\n";