6 ms·

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_respon

by pyninja 15y ago

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 https://github.com/adeel/picasso), a simple but functional framework I built on top of Pump.

irahul 15y ago
> In my view, the problems with WSGI are that it has an unpythonic API (see: start_response and environ), Why do you find `start_response` unpythonic?
- pyninja 15y ago
  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).
  - irahul 15y ago
    I see http://wsgi.org/wsgi/WSGI_2.0 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?
    - pyninja 15y ago
      Here is an example of a thread where it's discussed: http://mail.python.org/pipermail/web-sig/2009-November/thread.html#4224 http://mail.python.org/pipermail/web-sig/2009-November/threa...
    - clarkevans 15y ago
      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/004244.html http://mail.python.org/pipermail/web-sig/2009-November/00424...

by pyninja 15y ago

irahul 15y ago

> In my view, the problems with WSGI are that it has an unpythonic API (see: start_response and environ), Why do you find `start_response` unpythonic?

pyninja 15y ago
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).
- irahul 15y ago
  I see http://wsgi.org/wsgi/WSGI_2.0 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?
  - pyninja 15y ago
    Here is an example of a thread where it's discussed: http://mail.python.org/pipermail/web-sig/2009-November/thread.html#4224 http://mail.python.org/pipermail/web-sig/2009-November/threa...
  - clarkevans 15y ago
    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/004244.html http://mail.python.org/pipermail/web-sig/2009-November/00424...