Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

adeel.github.com

Post reply on HN
Print view View original

31–40 of 63 posts

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

#31

Post by dschobel »

jrockway wrote: post #22

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. 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 poi…

FTA:

Take advantage of existing WSGI tools. Pump comes with adapters for serving Pump apps with WSGI servers and converting WSGI middleware to Pump middleware.

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

#32

Post by pyninja »

irahul wrote: post #24
pyninja wrote: post #18

Earlier quoted context omitted.

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).

I see http://wsgi.org/wsgi/WSGI_2.0 mentions: > We could remove start_response and the writer that it implies. I searched for `wsgi start_response issues` and didn't get anything useful. Care to point out what's the fuss with start_response and why it's unpythonic?

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

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

#33

Post by pyninja »

justin_vanw wrote: post #29

"What WSGI should have been." 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. 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 th…

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.

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

#34

Post by clarkevans »

irahul wrote: post #24
pyninja wrote: post #18

Earlier quoted context omitted.

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).

I see http://wsgi.org/wsgi/WSGI_2.0 mentions: > We could remove start_response and the writer that it implies. I searched for `wsgi start_response issues` and didn't get anything useful. Care to point out what's the fuss with start_response and why it's unpythonic?

I think this was the original wart that started the whole WSGI 2.0 process. As I recall, it was PJE himself who recommended dropping start_response and replacing it with a return tuple of (status, headers, iterable). PJE comments in one thread that this isn't a reduction in features, but an improvement in usability:

"Note that in the WSGI 2 calling protocol, you would simply modify your return values, rather than needing to create a function and pass it down the call chain."

http://mail.python.org/pipermail/web-sig/2009-November/00424...

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

#35

Post by justin_vanw »

pyninja wrote: post #33
justin_vanw wrote: post #29

"What WSGI should have been." 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. 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 th…

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.

Werkzeug and WebOb already do what you are trying to do, and they do it in a completely fantastic way. I'm not saying that to discourage you from learning and contributing, but what do those two libraries do wrong that you are hoping to improve on?

In the meantime, don't bash WSGI until you understand why it is the way it is.

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

#36

Post by sigil »

pyninja wrote: post #33
justin_vanw wrote: post #29

"What WSGI should have been." 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. 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 th…

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.

As a special case, how about allowing the response body to be an iterable, and writing whatever blocks of data it produces back to the client?

You should also allow multiple headers with the same field-name, since that's in the spec.

I like the idea of Pump, and am tired of frameworks protecting me from HTTP.

EDIT: Looking at the WebOb code. It does have quite a few conveniences for working with HTTP messages. I'm not sure if copying bodies into temp files in order to make them seekable is a "completely fantastic way" of doing things, but if I were you I'd definitely read through WebOb to see what kind of problems you might be up against.

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

#37

Post by pyninja »

justin_vanw wrote: post #35
pyninja wrote: post #33

Earlier quoted context omitted.

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.

Werkzeug and WebOb already do what you are trying to do, and they do it in a completely fantastic way. I'm not saying that to discourage you from learning and contributing, but what do those two libraries do wrong that you are hoping to improve on? In the meantime, don't bash WSGI until you understand why it is the way it is.

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).

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

#38

Post by clarkevans »

pyninja wrote: post #37
justin_vanw wrote: post #35

Earlier quoted context omitted.

Werkzeug and WebOb already do what you are trying to do, and they do it in a completely fantastic way. I'm not saying that to discourage you from learning and contributing, but what do those two libraries do wrong that you are hoping to improve on? In the meantime, don't bash WSGI until you understand why it is the way it is.

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. Applic…

If you are really seeking to replace WSGI, then I'd encourage you do a bit more research, write a specification, get at least one more implementation, and then submit it as a PEP.

Documenting at this level is challenging & rewarding. The hard part about specification work, beyond explaining the design and providing adequate justification, is getting consensus. By doing so, you'll learn quite a bit, open yourself up for critique, and in the end perhaps provide a credible alternative.

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

#39

Post by justin_vanw »

pyninja wrote: post #37
justin_vanw wrote: post #35

Earlier quoted context omitted.

Werkzeug and WebOb already do what you are trying to do, and they do it in a completely fantastic way. I'm not saying that to discourage you from learning and contributing, but what do those two libraries do wrong that you are hoping to improve on? In the meantime, don't bash WSGI until you understand why it is the way it is.

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. Applic…

What middleware do you think are missing? In general, stuffing application logic into middleware leads to problems, so I don't think your premise is sound.

http://dirtsimple.org/2007/02/wsgi-middleware-considered-har...

I think your approach is harmful and will put developers who use this library in a very bad situation. You are putting a simplifying abstraction on top of HTTP. As with all simplifications, things which do fit perfectly in your tool become very easy, and things that don't fit perfectly become completely impossible.

Finally, I stand by my argument. Werkzeug and WebOb let you put the exact kind of simple interface on top of WSGI that you are attempting to, but with the benefits of not restricting you to a subset of HTTP, and interoperability with awesome tools like mod_wsgi.

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

#40

Post by justin_vanw »

sigil wrote: post #36
pyninja wrote: post #33

Earlier quoted context omitted.

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.

As a special case, how about allowing the response body to be an iterable, and writing whatever blocks of data it produces back to the client? You should also allow multiple headers with the same field-name, since that's in the spec. I like the idea of Pump, and am tired of frameworks protecting me from HTTP. EDIT: Looking at the WebOb code. It does have quite a few conveniences for working with HTTP messages. I'm no…

WSGI specifically specifies the response body as an iterable. Wheel, prepare to be reinvented.
Post reply on HN