Because nobody wants to admit that web applications are mostly just a bad idea.
Why so many Python web frameworks?
31–40 of 61 posts
Re: Why so many Python web frameworks?
#32Earlier quoted context omitted.
Well, ditto with Python and Django these days. There are other frameworks, each with their own strengths (werkzeug, web.py, bottle, etc.), but Django is the default choice. Back when this article was written there were at least five or six Python frameworks, all competing. If Django ever starts sucking, I'm sure one of them, or a completely new one, will step up to take it's place. Ditto for Rails. All part of the op…
While some people may choose Django per default, there are also quite a lot of people that will choose Flask/Werkzeug, Pyramid or one of the less popular frameworks. The Python web development community is very much divided into different, although largely cooperating, groups. Django is definitely not the default choice when it comes to web development in Python and I doubt anyone seriously involved in the Django pro…
I would disagree with that fairly strongly. While there are other choices for specific niches, for most web development Django is the first thing that most Python developers will look at, mainly due to it's user base and libraries.
Re: Why so many Python web frameworks?
#33Earlier quoted context omitted.
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 ).
Support for websocket is not yet fully baked into Mongrel2. The handshake etc needs to be done on the handler side. So gevent solution is a better bet at the moment. The alternative is to have a separate Tornado/Node.js to handle websocket alongside Django/Pyramid app. Mongrel2 does look promising, although it seems zedshaw is pretty resource tide at the moment.
Re: Why so many Python web frameworks?
#34Earlier quoted context omitted.
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 ).
Don't run on your whole app on gevent, but only the part which needs streaming/long poll. By decreasing the surface area, you can pin point the bugs arising due to monkey patching.
Re: Why so many Python web frameworks?
#35While we are at the topic of Python web frameworks, I seriously like Flask's design better than django's. True that django came out before SQLAlchemy or Jinja2 became popular/existed, but I would have loved it had they re-factored.
Django is great, with good re-usable components, but I like Jinja2 more than Django's templating. The argument for SQLAlchemy is more on the lines of I would prefer a standard ORM compared to everyone baking their own. SQLAlchemy used to be verbose, but the declarative extension now takes care of it.
Other things I like about flask are explicit app object, and context locals.
Re: Why so many Python web frameworks?
#36Doesn'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.
There is no Pope of Python to tell you "you can't write new code to do xyz, because someone else is already working on that."
How would that be enforced? Would someone's Python privileges be taken away?
What if the person working on xyz was inactive for a while? What if their xyz had a problem and they didn't want to fix it?
The "obvious way to do it" does not and was never, ever intended to bind anyone's hands from writing a library or app similar to something someone else wrote. It is a principle of language design, that it should give SOME consideration to readability and learnability rather than giving 100% of everything to nifty obscure features that help you write awesomely clever executable line noise.
Re: Why so many Python web frameworks?
#37Earlier quoted context omitted.
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
"Arguably" every API ever written is a domain-specific language.
Re: Why so many Python web frameworks?
#38Earlier quoted context omitted.
Well, ditto with Python and Django these days. There are other frameworks, each with their own strengths (werkzeug, web.py, bottle, etc.), but Django is the default choice. Back when this article was written there were at least five or six Python frameworks, all competing. If Django ever starts sucking, I'm sure one of them, or a completely new one, will step up to take it's place. Ditto for Rails. All part of the op…
While some people may choose Django per default, there are also quite a lot of people that will choose Flask/Werkzeug, Pyramid or one of the less popular frameworks. The Python web development community is very much divided into different, although largely cooperating, groups. Django is definitely not the default choice when it comes to web development in Python and I doubt anyone seriously involved in the Django pro…
Django has such numeric superiority that there is not a lot of point splitting hairs on whether it is "default." While it isn't in the stdlib and there are other good choices, Django might as well be the default, just as Rails might as well be the default in Ruby.
Re: Why so many Python web frameworks?
#39Because Python's motto is "There's more than one way to do it."
People writing tools to learn, or because the existing ones didn't suit their needs or tastes, occurs in every language and is very different from Perl-style "more than one way to do it".
It's ridiculous to act like the mere existence of multiple independent projects for one task is some kind of searing indictment of the "one obvious way" principle in language and API design.
Re: Why so many Python web frameworks?
#40While we are at the topic of Python web frameworks, I seriously like Flask's design better than django's. True that django came out before SQLAlchemy or Jinja2 became popular/existed, but I would have loved it had they re-factored. Django is great, with good re-usable components, but I like Jinja2 more than Django's templating. The argument for SQLAlchemy is more on the lines of I would prefer a standard ORM compared…
First, it's quite simple to replace Django's templating engine with Jinja. And second, Django's ORM isn't quite the equivalent of SQLAlchemy; the latter is supposed to be a true universal ORM, while the former is more limited, but focusing on the most important parts for a Web app.