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

51–60 of 63 posts

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

#51

Post by bruceboughton »

jessedhillon wrote: post #50
pyninja wrote: post #41

Earlier quoted context omitted.

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.

At the risk of sounding harsh: it's an incredible failure of time and project management for you to have written your own Python web framework as part of launching a startup.

This is particularly ironic given the premise of your startup is there are some things you don't have time to do that others can do for you.

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

#52

Post by nikcub »

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.

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

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

#53

Post by LeafStorm »

est wrote: post #49

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

For consistency. If there was a request object, there would need to be some sort of standard implementation that there was always access to so that the object could be properly instantiated, instance tested, etc. By using a plain old dict, you ensure compatibility at the cost of attribute access.

Also because WSGI is designed to be low-level, and if you want a request object you should really be using a library or framework.

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

#55

Post by moreyes »

pyninja wrote: post #30
irahul wrote: post #16

Earlier quoted context omitted.

You sure have put effort and the project looks good, but I am missing the purpose. If the problem it tries to solve is parsing environ to form response objects, or providing vanilla middlewares, that problem is very well solved by a wsgi library. Have you looked at werkzeug?

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…

It seems that what you ended up doing is, in fact, reimplementing things that were implemented zillions of times before. Am I wrong or the Pump middleware doesn't work for any WSGI app? If it had followed the WSGI middleware basic concept, you'd be closer to achieve the goal of reusable components across frameworks.

"Pump aims to replace WSGI entirely." <- this is very ambitious. :)

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

#56

Post by irahul »

carlhu wrote: post #42
ianb wrote: post #28

Earlier quoted context omitted.

Yes, but IMHO servlets got it all wrong, and WSGI took very little from servlets (though for instance Webware, a pre-WSGI framework did use the servlet model). But it owes much to the superior CGI model; replace processes with function calls and structure the response lightly and you have WSGI.

Ianb, may I inquire as to what is the difference you mean between servlets and cgi. A cgi written in perl for example, was essentially a perl servlet, I think. How is the CGI model fundamentally different from a servlet model, where your application code is given a request as a parameter to a function, and must return a response?

> How is the CGI model fundamentally different from a servlet model,

Since both are web server to application server interfaces, they aren't fundamentally different - the difference is cgi was language independent and hence defined for the common minimum. cgi couldn't have been defined in request and response objects - it would have caused trouble for languages which doesn't have objects.

> where your application code is given a request as a parameter to a function, and must return a response?

cgi is not given a request parameter - the request parameters are passed in the environment. And cgi doesn't return a response object - whatever it writes to stdout constitutes the response. cgi had to cater to all sorts of implementation - assuming request/response objects wasn't a possibility.

Servlets and cgi aren't fundamentally different, but I guess we can agree they are sufficiently different.

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

#57

Post by masklinn »

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…

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

if you don't like being "protected from http" why not write raw wsgi applications?

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

#59

Post by sigil »

masklinn wrote: post #57
sigil wrote: post #36

Earlier quoted context omitted.

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…

> I like the idea of Pump, and am tired of frameworks protecting me from HTTP. if you don't like being "protected from http" why not write raw wsgi applications?

How is a gateway that reads, buffers, and parses HTTP headers into an environment object [1] before turning it over to your "raw wsgi application" not protecting it from HTTP?

WSGI protects you from HTTP. CGI protects you from HTTP. mod_python and mod_perl protect you from HTTP. If you're unable to read and parse the complete HTTP request yourself -- perhaps incrementally, there's an idea -- you're protected from HTTP. Something is imposing policy like how many headers to accept, what the longest header should be, how to fold multiple headers with the same field-name, that it's okay to consume memory buffering all the headers, and so on.

In my ideal world, a web app server has access to the full HTTP request stream, calls an incremental HTTP parser [2] [3], and does whatever it wants along the way. If the typical use case is to accumulate a full request object and call a handler, fine, that can be made convenient. But the web app gets to decide.

Perhaps my issue is not with frameworks (in the sense of Django, Ruby, etc), but with web servers. Except, I view the infrastructure for hosting a web app inside a web server as yet another framework. The common use case is optimized for at the expense of the less common use cases, which become more painful than they should be. Or sometimes outright impossible.

TL;DR -- Libraries over frameworks. In Soviet Framework Russia, you don't call code...code call YOU.

[1] http://www.python.org/dev/peps/pep-0333/#environ-variables

[2] https://github.com/ry/http-parser

[3] https://github.com/mongrel/mongrel/tree/master/ext/http11

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

#60

Post by sergeys »

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…

WebOb maintainer here. What's your alternative to copying body to a temp file if you need to make it seekable?
Post reply on HN