pyninja

> Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer.

I'm curious, have you ever actually had to do this? Even Rails only just got this feature in 3.1 (http://weblog.rubyonrails.org/2011/4/18/why-http-streaming).

pyninja

hace 15 añosdiscuss

I agree with you, but Pump is not a web framework. You are not supposed to write your application with Pump. Picasso is a framework I built on top of Pump (https://github.com/adeel/picasso) that's more suitable for that.

(I can see how you could get a mistaken impression from reading the discussion on HN, though.)

pyninja

hace 15 añosdiscuss

I'd like to do that, but I'm afraid of how much time and effort it would take. I really just wrote Pump/Picasso to use at our new startup, Beagle (http://beagleapp.com). I was expecting roughly this kind of response from the Python community, but who knows, maybe someone will use it.

pyninja

hace 15 añosdiscuss

Werkzeug and WebOb are not what I'm trying to do.

I'm reposting a reply I made earlier to irahul:

Pump aims to replace WSGI entirely. That is, I believe it does a better job of what WSGI was intended to do.

I understand your point that web developers don't necessarily work with WSGI on a day-to-day basis. But if you look at the Ruby web community, Rack middlewares are much more prevalent than WSGI middlewares. Application developers (as opposed to framework developers) often add functionality as a Rack middleware, so that it can be reused in different applications, even using different frameworks. Why isn't that happening with Python as much? In the Python world, instead of writing even simple middlewares to for basic functionality like https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/co..., every framework ends up reimplementing it. I believe this is because the WSGI API is ugly and not as easy to understand as it could be (just look at the average WSGI middleware).

pyninja

hace 15 añosdiscuss

Thanks for the feedback. I'm not willing to accept that WSGI couldn't be this simple. Pump's specification is modeled on Ring for Clojure (https://github.com/mmcgrana/ring), and I'm sure there's a way Ring gets around the issues you mention. I'd never had to do any of those things before but I'll look into it now.

pyninja

hace 15 añosdiscuss

Here is an example of a thread where it's discussed: http://mail.python.org/pipermail/web-sig/2009-November/threa...

pyninja

hace 15 añosdiscuss

Pump aims to replace WSGI entirely. That is, I believe it does a better job of what WSGI was intended to do.

I understand your point that web developers don't necessarily work with WSGI on a day-to-day basis. But if you look at the Ruby web community, Rack middlewares are much more prevalent than WSGI middlewares. Application developers (as opposed to framework developers) often add functionality as a Rack middleware, so that it can be reused in different applications, even using different frameworks. Why isn't that happening with Python as much? In the Python world, instead of writing even simple middlewares to for basic functionality like https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/co..., every framework ends up reimplementing it. I believe this is because the WSGI API is ugly and not as easy to understand as it could be (just look at the average WSGI middleware).

pyninja

hace 15 añosdiscuss

The problems with start_response have been discussed at length in Web-SIG. As far as I know, they're planning to remove it from the spec in WSGI 2.0 (whenever that's published).

pyninja

hace 15 añosdiscuss

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

pyninja

hace 15 añosdiscuss

Yes, Pump was heavily inspired by Rack and especially Clojure's Ring (https://github.com/mmcgrana/ring).

pyninja

hace 15 añosdiscuss

I hadn't seen this, looks interesting.

pyninja

hace 15 añosdiscuss

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 really simple to write a web framework: just implement the routing and glue together a bunch of middlewares. For an example, see Picasso (https://github.com/adeel/picasso), a simple but functional framework I built on top of Pump.

Submissions

Timed: a command-line time tracker (written in Python)

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

comments