Why so many Python web frameworks?

http://bitworking.org/news/Why_so_many_Python_web_frameworks

by ColinWright • 14 years ago

110 59 14 years ago

espeed2• 14 years ago

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...).

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.

ak2172• 14 years ago

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!

warp• 14 years ago

That doesn't sound correct. Both PEP 333 and 3333 specifically mention that the server may use chunked encoding.

anthonyb6• 14 years ago

Eventlet seems to support it: http://blog.eventlet.net/2010/02/12/scalable-wsgi-compatible...

jemeshsu2• 14 years ago

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.

espeed2• 14 years ago

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

wycats• 14 years ago

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.

anthonyb6• 14 years ago

Language features and third party libraries are different things though.

nerfhammer2• 14 years ago

arguably, arguably all the 'interfaces' needed to make code do a web site end up being a domain-specific language

fennecfoxen• 14 years ago

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.

anthonyb6• 14 years ago

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_moto2• 14 years ago

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).

unimpressive• 14 years ago

If you read to the end of the article it tells you (Implies) that making Yet Another X is a bad idea, and that you should really go work on an already established project.

EDIT: Or rather, skimmed to the end of the article. (Like I did because I have no interest in building a python web framework and thought the title was sarcastic.)

reactor• 14 years ago

"There should one - and preferably only one - obvious way to do it" is applicable only at language level, not at application level. These are just another applications and one cannot enforce a rule that "there should be only one application/solution for a problem at hand", is it ?

FraaJad• 14 years ago

There is a difference between reducing entropy in core language vs individual developers' freedom to build things (libs, frameworks) as they see fit.

Your comment is surprising given your expertise. Guess you are not immune to taking pot shots at Python.

DasIch2• 14 years ago

This rule applies to the language and APIs on a project level but it doesn't extend beyond that.

If you look at the web frameworks that are available or libraries such as requests you also see why this is a very good thing.

reuser5• 14 years ago

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.

cd34• 14 years ago

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

anthonyb6• 14 years ago

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

jordanmessina• 14 years ago

And uses python 2.4

sekou• 14 years ago

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.

jrockway2• 14 years ago

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

nerfhammer2• 14 years ago

you forgot to enclose your answer in a <sardonic> tag

reuser5• 14 years ago

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.

jrockway2• 14 years ago

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.

cbs• 14 years ago

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.

yuest• 14 years ago

Now, nodejs may be a better choice.

hashfold• 14 years ago

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.

eli_gottlieb• 14 years ago

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

irahul7• 14 years ago

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• 14 years ago

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.

irahul7• 14 years ago

> 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).

rlander2• 14 years ago

Totally agree with you on this. I think Flask is Django done right and I've been beating that drum for quite some time (see, for example, my comments on the settings file [1]).

The core devs claim that SQLAlchemy and Jinja weren't around at the time Django was developed, and that's fine. But in 2012, Jinja2 and SQLAlchemy are clearly better alternatives to Django's defaults. So why not incorporate them?

Django doesn't even have first class support for Jinja2 templates, let alone the python HAML variants.

What's ironic is that a few years ago Django was known for being loosely coupled when compared to Rails, which was considered monolithic ("my way or the highway"). Nowadays Rails is the flexible framework, allowing for different ORMs and templating systems, while Django is now the monolithic framework.

Don't get me wrong, I love stability. But when a great percentage of developers are using hacks to get around the default configuration system and to support excellent external libraries like Jinja2 and SQLALchemy, something is very wrong.

[1] http://news.ycombinator.com/item?id=3556929

Chris_Newton3• 14 years ago

We've been using Flask recently, and I do like the simple, no-nonsense approach. Our project is modest in its library needs, and it's nice to have a useful toolkit without imposing a heavyweight structure on our code.

There are significant limitations with some of these frameworks today, though. For example, lack of byte range/partial content support is bad news if you're serving large files (think multimedia).

We're still investigating options here, but WSGI doesn't seem ideally suited to working that way, and as far as we can tell quite a few of the "microframeworks" lack any kind of support for returning partial content automatically. The concern seems to be that WSGI would need the application to generate a complete response even if it was going to serve only part of it as a 206, because there's no standardised part of the routing set-up that says "I need these byte ranges from whatever full response you would have given me".

A common philosophy seems to be that such files should be served statically by your front-end web server anyway, but that is not sufficient in all cases. For example, you might need to process the request through your framework to generate the response on demand, implement access controls, or integrate with a custom logging/analytics framework.

[Edits: Trying to clarify key points.]

irahul7• 14 years ago

Depending on your use case, you can either use X-sendfile header - validate request, then return a X-sendfile response for your front-end server; or use gevent to stream the response.

hessenwolf• 14 years ago

We're working with flask at the moment, and I have found it excellent. I really don't want to be bothered by anything to do with the web framework because I am already busy with the other stuff, and I've been able to ignore it all with flask because it is simple and lightweight it works.

We used pylons for the last project, and there are areas I still don't make improvements on because it is too much effort to get into it.

6ren• 14 years ago

kid seems to be down: http://www.kid-templating.org/

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

dspillett• 14 years ago

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.

rlander2• 14 years ago

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• 14 years ago

Genshi is a much better replacement for Kid. http://genshi.edgewall.org/

NathanRice• 14 years ago

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 :)

dignan• 14 years ago

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

This is also an article from 2006.

Why so many Python web frameworks?

Related Stories