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

41–50 of 63 posts

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

#41

Post by pyninja »

clarkevans wrote: post #38
pyninja wrote: post #37

Earlier quoted context omitted.

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 f…

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.

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

#42

Post by carlhu »

ianb wrote: post #28
bobbyi wrote: post #17

Earlier quoted context omitted.

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"); } }

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?

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

#43

Post by voidfiles »

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.

Doing something simple is fine, but what I think other people are saying is that pump is reductively simple.

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

#44

Post by mkramlich »

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.

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

#45

Post by mkramlich »

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…

I'm pretty sure the plural of middleware is middleware.

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

#46

Post by mkramlich »

pyninja wrote: post #41
clarkevans wrote: post #38

Earlier quoted context omitted.

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 f…

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.

I'd advise you to spend more of your time on building what's the core of your new business, because there are tons of higher priority things you'll have to accomplish. Web frameworks, even "lightweight" ones, in Python, is/was not an unsolved problem. Lots to choose from. Pick and go.

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

#47

Post by MostAwesomeDude »

radarsat1 wrote: post #7

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

WebSockets is not HTTP and should not be handled like HTTP. I just reimplemented a WS wrapper by removing its dependency on HTTP stuff, and ended up decreasing its LOCs and complexity.

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

#48

Post by Confusion »

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…

I think the pertinent question here is: what do you think 'WSGI was intended to do.'? From the responses here, it seems your answer to that question is a distinct subset of what WSGI actually intends to do. Which is why Pump offers only a subset of the abilities of, for instance, Werkzeug.

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

#50

Post by jessedhillon »

pyninja wrote: post #41
clarkevans wrote: post #38

Earlier quoted context omitted.

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 f…

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.
Post reply on HN