Why so many Python web frameworks?
bitworking.org
Why so many Python web frameworks?
1–10 of 61 posts
Re: Why so many Python web frameworks?
#2Building 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.
Re: Why so many Python web frameworks?
#3Doesn'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.
Re: Why so many Python web frameworks?
#4Doesn'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.
Re: Why so many Python web frameworks?
#5Doesn'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.
Rumor (and by rumor I mean a couple of opinionated coworkers) says: the Python community has a lot of cases of "This project didn't have the feature I needed and has a couple of problems, so I went and wrote a whole new one with a different set of problems." By contrast, the Ruby community settles down on one, maybe two things as the primary way to do it.
This article lends weight to the rumor.
Re: Why so many Python web frameworks?
#6Building 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.
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!
Re: Why so many Python web frameworks?
#7Note that the original article has a publish date of 2006-09-05.
Re: Why so many Python web frameworks?
#8Doesn'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.
Rumor (and by rumor I mean a couple of opinionated coworkers) says: the Python community has a lot of cases of "This project didn't have the feature I needed and has a couple of problems, so I went and wrote a whole new one with a different set of problems." By contrast, the Ruby community settles down on one, maybe two things as the primary way to do it. This article lends weight to the rumor.
It works the way that most open source third party libraries do: There'll initially be some hacked together stuff, then a couple of contenders will emerge, copying each other's features. After the dust has settled there'll be a few decent libraries.
Examples that I can think of off the top of my head are freshen/lettuce/behave, there were also a bunch of XML parsers leading into elementree (which is now in the standard library). In Ruby you have Rails, Sinatra, and a couple of other frameworks, as well as Mongrel2 and friends to run it all.
Re: Why so many Python web frameworks?
#9Doesn'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.
Rumor (and by rumor I mean a couple of opinionated coworkers) says: the Python community has a lot of cases of "This project didn't have the feature I needed and has a couple of problems, so I went and wrote a whole new one with a different set of problems." By contrast, the Ruby community settles down on one, maybe two things as the primary way to do it. This article lends weight to the rumor.
Seems like it too. I like Python language because whenever I read them I can guess/kind of know what it's trying to do (unlike Ruby) despite my short learning session of Byte of Python.
But when it comes to web-framework, boy... this one is tough. I lost count on how many Python web-framework or web-library out there (feel free to debate the semantic of Flask vs Bottle vs Django vs Pylons vs Pyramid vs Plone vs Zope).
Re: Why so many Python web frameworks?
#10Note that the original article has a publish date of 2006-09-05.
This article would date back to around the time of Turbogears, CherryPy, etc. before Django became the 'default' solution.