Note that the original article has a publish date of 2006-09-05.
And uses python 2.4
Why so many Python web frameworks?
21–30 of 61 posts
Re: Why so many Python web frameworks?
#22Earlier quoted context omitted.
I'm really interested in this for building simple API endpoints. I tried a bunch of WSGI servers and lightweight frameworks to serve stuff on them, but realized that there is no way to support chunked request content encoding with WSGI (the WSGI spec is not compatible with it, so WSGI can't support HTTP/1.1). Hopefully Brubeck is good, please let us know if there's anything else worth checking out!
That doesn't sound correct. Both PEP 333 and 3333 specifically mention that the server may use chunked encoding.
OK, I should have made this more clear, and I'll edit the original. WSGI is not compatible with chunked encoded POST request bodies.
Re: Why so many Python web frameworks?
#23Because Python's motto is "There's more than one way to do it."
Re: Why so many Python web frameworks?
#24Because Python's motto is "There's more than one way to do it."
you forgot to enclose your answer in a tag
Re: Why so many Python web frameworks?
#25Doesn't making a new X because it's easy violate the "There should be one-- and preferably only one --obvious way to do it" rule? From the way the Python community talks about its strengths, I'd expect there to be pressure against creating a new X just because you can.
Language features and third party libraries are different things though.
arguably, arguably all the 'interfaces' needed to make code do a web site end up being a domain-specific language
Re: Why so many Python web frameworks?
#26If the paradox of choice is making the options an uncomfortable situation for you, just write down the top 6 and roll a die. Problem fucking solved. Or act like a grown up and evaluate your options.
Re: Why so many Python web frameworks?
#27Building a non-WSGI Python framework would be useful because WSGI does not support websockets ( http://librelist.com/browser//flask/2011/12/30/websockets/#b... ). A ZeroMQ-based framework might be interesting -- Brubeck ( http://brubeck.io/ ) is an example of this. Nginx ( https://github.com/FRiCKLE/ngx_zeromq ) is starting to get support for ZeroMQ, and Mongrel2 ( http://mongrel2.org/ ) was designed around it.
Python's greenlet libraries such as Gevent & eventlet makes websocket type of applications possible. It is not difficult to add in websocket support into WSGI frameworks such as Pyramid/Flask. One example http://blog.abourget.net/2011/3/17/new-and-hot-part-4-pyrami.... You can have both WSGI and websocket in the same stack.
Re: Why so many Python web frameworks?
#28Building a non-WSGI Python framework would be useful because WSGI does not support websockets ( http://librelist.com/browser//flask/2011/12/30/websockets/#b... ). A ZeroMQ-based framework might be interesting -- Brubeck ( http://brubeck.io/ ) is an example of this. Nginx ( https://github.com/FRiCKLE/ngx_zeromq ) is starting to get support for ZeroMQ, and Mongrel2 ( http://mongrel2.org/ ) was designed around it.
Python's greenlet libraries such as Gevent & eventlet makes websocket type of applications possible. It is not difficult to add in websocket support into WSGI frameworks such as Pyramid/Flask. One example http://blog.abourget.net/2011/3/17/new-and-hot-part-4-pyrami... . You can have both WSGI and websocket in the same stack.
You can, but monkey patching is not always ideal (https://www.google.com/search?q=gevent+monkey+patch+issues).
Re: Why so many Python web frameworks?
#29Now, nodejs may be a better choice.
Re: Why so many Python web frameworks?
#30because one can't solve all the specific use cases people have.
or may be Python is not so generic to help solve these use cases.