

Why so many Python web frameworks? - ColinWright
http://bitworking.org/news/Why_so_many_Python_web_frameworks

======
espeed
Building a non-WSGI Python framework would be useful because WSGI does not
support websockets
([http://librelist.com/browser//flask/2011/12/30/websockets/#b...](http://librelist.com/browser//flask/2011/12/30/websockets/#b8215c55f7d5121fed8b1db3d51b9ce4)).

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.

~~~
jemeshsu
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...](http://blog.abourget.net/2011/3/17/new-and-hot-
part-4-pyramid-socket-io-gevent/). You can have both WSGI and websocket in the
same stack.

~~~
espeed
You can, but monkey patching is not always ideal
(<https://www.google.com/search?q=gevent+monkey+patch+issues>).

~~~
jemeshsu
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.

------
cd34
Note that the original article has a publish date of 2006-09-05.

~~~
anthonyb
This article would date back to around the time of Turbogears, CherryPy, etc.
before Django became the 'default' solution.

------
irahul
While 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.

~~~
BerislavLopac
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.

~~~
irahul
> First, it's quite simple to replace Django's templating engine with Jinja.

Yes, it is. But most of the applications are tightly coupled with Django's
ORM(auth, for eg, which I use very frequently), and in the end, I end up
maintaining two types of templates which I don't like.

> And second, Django's ORM isn't quite the equivalent of SQLAlchemy;

No, it isn't. But SQLAlchemy does what django's orm does, and then some.

I would prefer a compartmentalized model, where a web framework doesn't
implement templating or ORM, provided a robust solution exists. The templating
engine and ORM should be independent libs, and the web framework should glue
them together, possibly adding a declarative layer above
them(render_to_response, declarative ORM etc).

------
rlander
This post is from 2006.

Here's a more recent article in the same "DIY Python Framework" spirit, which
is longer but quite good: <http://docs.webob.org/en/latest/do-it-
yourself.html>

~~~
SimHacker
Genshi is a much better replacement for Kid. <http://genshi.edgewall.org/>

------
wycats
Doesn'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.

~~~
fennecfoxen
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.

~~~
anthonyb
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.

~~~
hello_moto
Yep, except nobody cares about "the rest" and Rails becomes almost de-facto
choice for web-app with Sinatra trailing for the so-called "API" project
(whether that choices make sense or not is not of my concern, in Java, API ==
XYZService.java with a facade skeleton implementation utilizing JAX-WS [SOAP,
WS-*], JAX-RS [RESTful], or Servlet (Web) all deployable easily in 1 JAR).

~~~
anthonyb
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 open-source circle of life :)

~~~
DasIch
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 project would
ever claim that.

~~~
reuser
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.

~~~
tbatterii
You sure about that? It is my understanding that Zope/Plone has a fairly
sizable community. They're just not as loud on the web as other framework
fans. No one will know for sure until they are all counted though.

~~~
reuser
I'm heuristically pretty sure. From my personal experience talking to people,
and from some surveys or other I have casually looked at over the years, what
is mentioned most in job ads and mailing lists, heuristic stuff like that. The
same kind of stuff which leads people to say that Rails is much more popular
than other Ruby frameworks.

I would love to see a scientifically exact census but I don't think it can be
done. Maybe PyPI could roughly tell the story? But you won't get a real
unique-users count unless your logging identifies unique users, who wants
that?

Please understand: I am not a big Django promoter, I disagree with many of its
design principles, and I don't think that other things are "dead". I know that
there are reasonable numbers of people out there using Zope/Plone, Flask,
Pyramid, and other things. Just because Django is huge doesn't mean they are
nothing or not worth looking at. I believe Rails is significantly bigger than
Django, but that doesn't mean I'm switching to Rails.

------
sekou
It may be easy to link together well developed Python libraries for web
development, I think it's one of the benefits of working in Python, but full
stack frameworks like Django that provide a somewhat unified API exist at
least in my mind on a different level of framework. I think there is a
spectrum of complexity represented in the list of frameworks linked by the
author, and the word "framework" is used to describe a lot of different kinds
of situations.

------
NathanRice
A lot of people will make snide remarks when someone says they are creating
their own framework, but obviously if someone has evaluated the existing
frameworks and still decides to do it, there is an unscratched itch. A lot of
people who aren't happy with the larger monolithic frameworks have adopted
flask (myself included) as a simple base to build more interesting things on.

There are a number of things no framework I have yet run into does well:

1\. Unification of client side and server side events. With options like
Backbone or (ugh) ExtJS on the client side, there is a lot to be gained from a
coupled event subsystem over websockets, or via server sent events.

2\. A true viewmodel based page composition framework, where components are
abstract view elements with data bindings on the server side, which then have
associated renderers for the output to the client.

I've played with both of these, and found them to have a lot of advantages
over standard template + ajax + callbacks style of design, though creating a
library for others is a lot more work than hacking something for yourself :)

------
jrockway
Because Python's motto is "There's more than one way to do it."

~~~
reuser
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.

~~~
jrockway
I've never actually noticed "one obvious way". There are a couple ways to do
almost everything in Python; loops or map, Twisted or threads, unittest2 or
nose, and so on. I like Python, but human nature pushes everything towards
"there are many ways to do it", and humans have influenced the direction of
Python.

I prefer Perl's approach of embracing more than one way to do things. I don't
really want there to be 8 ways to do one thing, but it's just a more realistic
outlook. You go into Perl knowing that you are going to have to try a bunch of
different things to see what fits your mental model, instead of being told
what to do. (I used Python at a Bank where they wrote their own style guide,
completely different from the standard Python style guide. WTF? Humans have a
way of ruining everything.)

Ironically, many things in Perl have converged into "One Obvious Way";
PSGI/Plack for web frameworks, Test::Builder for unit tests, and so on.

~~~
irahul
> There are a couple ways to do almost everything in Python; loops or map,
> Twisted or threads, unittest2 or nose, and so on

There are always more than 1 ways to do something, but Python tries to be
directive towards the recommended way for the core.

For the given snippet, using reduce for loops is frowned upon; nothing is
stopping you from doing it, but the general opinion is you shouldn't do it. I
think that counts as _there being an obvious way_.

    
    
        def pipe(val, fns):
            return reduce(lambda val, fn: fn(val), fns, val)
    
        def pipe2(val, fns):
            for fn in fns:
                val = fn(val)
            return val
    
        fns = [lambda x: x + 1, lambda x: x * x]
        print pipe(5, fns)
    
        print pipe2(5, fns)
    

As far as maps and list comprehension go, that isn't clear-cut but people
incline towards comprehensions.

<nitpick> Twisted(reactors) and threads implement two different things which
serve different purposes, and unittest2 is a lib while nose is a test runner.
</nitpick>

That said, there is always going to be many ways to do something, but it helps
if the core tries to stick with a uniform way to do things.

------
dspillett
Because writing your own web framework seems to be a "rite of passage" for
Python programmers, or did around the time that article was first written. The
same thing is happening with node.js right now.

------
dignan
He doesn't build a framework. He uses libraries to create a web application.

This is also an article from 2006.

------
6ren
kid seems to be down: <http://www.kid-templating.org/>

Here's wiki on it:
<http://en.wikipedia.org/wiki/Kid_%28templating_language%29>

------
eli_gottlieb
Because nobody wants to admit that web applications are mostly just a bad
idea.

------
hashfold
because 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.

------
yuest
Now, nodejs may be a better choice.

------
cbs
If 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.

