5 ms·
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 w
by teej 15y ago
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 with any Ruby web framework & Ruby web server combo I choose. No special setup required.
-----
[1] http://rack.rubyforge.org/ http://rack.rubyforge.org/
- pyninja 15y agoYes, Pump was heavily inspired by Rack and especially Clojure's Ring (https://github.com/mmcgrana/ring https://github.com/mmcgrana/ring).
- irahul 15y agoI don't get the purpose. WSGI was meant to low level to cover the common minimum. If you want request, response semantics, use a higher level library - I use werkzeug which wraps wsgi, or flask which is small web framework built on werkzeug. I don't think anyone other than wsgi library implementors code to WSGI. WSGI would be a problem if that's how python web programming was to be done - but that's not the case.
- BarkMore 15y agoI like how the circle if inspiration loops back to Python: Python WSGI inspired Ruby Rack. Ruby Rack inspired Clojure Ring. Clojure Ring inspired Python Pump.
- irahul 15y ago# 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.
- pyninja 15y ago# Pump def app(request): return { "status": 200, "headers": {"content_type": "text/plain"}, "body": "Hello World"}
- irahul 15y agoYou 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?
- pyninja 15y agoPump 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/params.py https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/cookies.py 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).
- moreyes 15y agoIt 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. :)