I'm currently working with TurboGears. I evaluated pylons, django and web.py a year ago and made my decision. Here is a summary of my opinions (note from a year ago).

pylons: didn't really like the lack of decorators, didn't seem to be an ORM of choice, docs looked weak although the wiki was well stocked with recipies

django: really well documented. Seemed to be HUGE and I felt intimidated by it. It wasn't clear to me I could strip it down to what I needed. Didn't seem very modular, you can only use the Django ORM and templating engine.

web.py: Far to simple for my needs, you need to build nearly everything from scratch, simple to learn because there is nothing there!

I chose Turbo Gears because it seemed easier to chose the components you want to use. The idea that the TurboGears community picks best of breed python components and integrated them really appealed to me. This is both good and bad but in general I think it's been good for the project.

A year later and I haven't been disappointed. The TG community is really friendly as well :) TG is working with the pylons team for the next version of TurboGears and I know there has been a lot of code sharing between the groups.

That's my 2p, good luck.

"Didn't seem very modular, you can only use the Django ORM and templating engine."

Very common misunderstanding. You can use Django with SQLAlchemy (I have done in the past). You can use Django with Genshi, or Cheetah, or whatever template engine you like (I would strongly recommend using something like Genshi for outputting XML). It's usually better to stick with the Django ORM though as it will let you use many of the excellent extension applications for Django (such as django-mptt, django-tagging or the Django admin package). The same is not true for the Django template system - replacing it with something else has no disadvantages at all that I can think of.

I personally like web.py:

PROS: * Light and fast, * Really flexible, * Really easy to learn, * Easy to install, * Nice error reports (mostly copied from Django), * No database ORM

CONS: * No database ORM, just some helper functions: insert(...), update(...), select(...), etc. You must also build the DB tables by yourself. * Limited documentation.

I stopped using web.py after I had to correct Aaron when he recommended a 'session' implementation that had a massive gaping security hole.

http://groups.google.com/group/webpy/browse_thread/thread/2f...

If he couldn't spot that when he posted, I don't trust him to spot any other problems with web.py

For a second I didn't get what the big deal was here. Sure you have to keep your pickled python objects in a secure place on your server. Sure you could have problems if someone could get at those, but they would need to crack your server first and then figure out how your app worked. If they could do that you're hosed anyway...

Then it hit me.

He was suggesting you give the pickled object back to the client in the session cookie and load whatever the client sends later right back into the interpreter. Whee!

> He was suggesting you give the pickled object back to the client in the session cookie and load whatever the client sends later right back into the interpreter. Whee!

I've done that with signed cookies.

I imagine you didn't store any per-session state on the server as well, so I'm curious about what you used to validate the cookie.

I secretly salted the cookie.

Think HMAC, though I used two completely different keys, rather than generating them from one key, added an optional step of appending the client's IP address after the first hashing (with the first key) and before the second one.

(The second hashing in HMAC is designed to prevent collision attacks (even on weak algorithms like MD5), since you'd essentially have to find a fraudulent input that collides twice: once when hashed, and once more when its hash is hashed).

My implementation also allowed the data to span an arbitrary number of ~4kb cookies). Firefox maxed out at around 0.5MB, though if you're using that much session data, you may want to rethink your app design... ;)

There wasn't any encryption involved in his suggestion. :D

He is doing a good job so far. Anyway, I believe he isn't the only developer of web.py anymore.

Seconded. It's not really a framework as much as a url mapper. Plus, it's quite small so if you're having trouble understanding something, the source is available.

Limited Documentation = really almost non-existent, except few samples, and few lines here and there in their website.

I am not sure it is by laziness, or it is purposely done to scare n00bs away from it.

It's a pitty when somebody takes the time to built a decent and useful framework, but just hinders its adoption, by not going the extra mile and providing good documentation.

I am quite against database ORM, so that's no con for me. Documentation isn't great either but things are generally very easy to figure out.

My only cons (last I checked):

- Connecting to multiple databases is kind of a hack.

- Depreciation of cheetah over aaron's templating system.

So, it's just about perfect for me.

hi how can i reach u?

I can help. See profile.

Use Django for any web publishing app - blogs and news sites are its real strength. I'm using Django for what I would consider edge cases (eg building on-line databases) and it's not a perfect fit, although I think it will work.

If you learn Django, I'm sure you won't regret it. I don't think it's "huge" at all: it's compact and usable.

I prefer Pylons. I've built all sorts of things with it:

* A RSS-rewriting, caching "proxy" for the News.YC feed

* A search engine for 2 gigs of email, going back to 1995

* A customized CMS-like app

* And now, my blog, which I'm almost done writing; I keep making changes to the architecture.

TurboGears 2, which some have recommended, is being built on top of Pylons.

I like Pylons. I've used it for both big sites (http://www.bittorrent.com/) and small ones (http://codepad.org/), and it's been pretty good for both.

In Django you could build the core of either of those two examples in an afternoon. I have done so just for practice. Yes, you won't use 90% of Django's potential. But the 10% you do leverage lets you build something like that very easily.

For a simple blog you would need to write only a few views and templates, and then I would use the the built-in admin system to manage the content. Same sort of situation for the simple news site.

I always get flamed for suggesting to not reinvent the wheel, but if you want to do build something like a quick news site, why not leverage all the pre-existing work you can. Technology is not your differentiating factor. /rant

I hate the name, but I've been very happy with cherrypy. Some things seemed too big (Django, Turbogears) and I liked how cherrypy managed routing and config details more than I liked pylon's implementation.

Whatever makes you happy and lets you get the job done efficiently.

Don't get stuck in paralysis through analysis. Find something that seems good and go with it.

Pylons definitely

django.

Could you explain why you would use django over the others? Does pylons have too much magic? I've never used django and am curious if you have used the other frameworks.

I have only used Django, Rails, CakePHP and raw PHP. Django has a superb ORM layer (beats Rails 10-0), where relations are really well implemented, as members of the model. Selects are easy, and can be chained (as filters). In Rails (even 2.0) I had to use find(:all, condition => <SQL fragment>. That is so not hiding the db layer. Generally, there is much less to none auto-magic. This is a thing I quite disliked in Rails, both as a beginner and beyond. I like to keep most things explicit. I find it baffling that Rails is considered easy to understand. Due to the auro-magic, I found the learning curve pretty steep.

what about TurboGears? I like the idea of having a larger unifying framework based on smaller independent projects.

Btw, I should add that I'm asking from the perspective of somebody moving towards a Pythonic framework. I've spent the better part of today learning Python, and so far I love it!

I've used TurboGears around 2006 and moved away because it lacked pylons/django/weby like url dispatching, and I found it too hard/impossible to customize the widgets. Also, the main developers droped it in favor of pylons or something else, so, I thought it was pretty much the end of the project. I am suprised that it is still around.

Django. You won't regret it! The url mapping, the views and escpecially the template engine is fantastic. Almost every element of Django behaves as it should be. Strict separation from code and layout for example.

If you want to be adventurous, you can also look at Werkzeug (a collection of WSGI utilities) and choose whatever ORM (SQLAlchemy, SQLObject, etc) and template system (Jinja, Mako, etc) you want.

Pylons is also WSGI-based, and lets you use whatever ORM and templating components you want (although Mako is the default for templating).

For very small projects (i.e. only a handful of users, no serious performance requirements), I typically use web.py (http://webpy.org). It's very simple and offers only very basic functionality, but does a good job of staying out of the way and generally letting you do whatever you want. I've heard from friends that Pylons is also a good option, but I found it to be more complex than I really needed.

hi how can i reach u?

mod_python + mako

Edit: I started with Pylons but was simply overwhelmed by the complexity. I checked out but didn't use TurboGears and Django so I don't have to much to say about them. web.py is nice, but it's immature and some things don't seem to work the way they should.

So I rolled my own (if you can call it that) using the db module from web.py along with Mako and mod_python.

Yes before the WSGI zealots freak out let me say that it is NOT a WSGI solution but I could care less. It just works.

For smaller web projects? http://webpy.org/

It's very simple, yet powerful enough to let you do pretty much anything you need to.

Just as a warning. Its not listed here, but stay away from Zope3/Plone for a while :).

Why, may I ask?

I'm contemplating to skip Zope3 to learn Plone. I'm also tinkering with the idea of purchasing Plone 3 book by Martin Aspelli. I heard the book is good and it gives you enough information about Zope3 to learn Plone.

I wrote a lot about it in a blog post this summer.

http://thingsilearned.wordpress.com/2007/08/14/zope3plone-to...

Its a great CMS with a lot of awesome features. Its just incredibly difficult to pick up and work with, especially in its current state.

well django is definitely a good starting point.. but turbogears has very advanced templating engine... but for a beginning (like yours truly), django is very easy to setup and get it running..

django. this isn't an even reasonable question to be asking.

It's reasonable to try to narrow the landscape down. There's a lot of information out there.

Although I agree, Django is really your best choice here.