Recommendation for straight-forward python frameworks

Question

Although I have quite a few years of experience of building web applications in Java, I've not really done much web development in the more lightweight 'LAMP' style.

I've recently picked up python and am quite liking what I see so far, but there isn't an 'obvious' choice for which web framework to use, as it seems there are a number of well-used options.

While I'd like to have a nice rich framework to use, I would prefer a framework that was accessible rather than one that "did a lot of code for me". Mainly because if I then need to customise something, I need to get involved in a lot of that boilerplate code.

So given this thinking, what would be the best option for Python web development?

Answer 1

Check out Django, should go 1.0 very soon, final beta will be on the 14th

Answer 2

Your options are basically:

• Django which is about to go 1.0 and is probably the "leader"
• TurboGears which, despite being about to go 2.0, is probably less mature.
• web.py which is only at 0.3 and doesn't seem to be very heavily developed

I've used them all and I found that web.py was the one that I enjoyed using the most. It does less for you but also gets out your way pretty effectively so you can just do what you need to and no more. It's probably the one that meets your accessibility/no boilerplate requirement the best. This comes at the cost of being (by far) the least mature.

Turbogears and Django were a much of a muchness (maybe TurboGears just shaded it). The thing to remember with TurboGears though is that it is mostly a lot of glue to bind together lots of other projects into a framework. When things go wrong, it can often be in a non-TG library and (slightly) harder to figure out what's gone wrong where, and how to get help. Django is a little more cohesive.

Here's the caveat though, I've never deployed anything of any significance with them. Everything I have written has been a prototype or a lightly used internal system. Very soon we'll be starting a much larger, external project and I think that we will have to make a call based on which we think will be the most stable and easy to keep performant. The programming models are close enough between all three that these criteria will be the deciders.

Answer 3

Pylons is particularly suited for your situation. It uses lots of standard libraries (Paste, Beaker, Mako, SQLAlchemy, Routes etc...) and more or less just acts a 'glue' between them. Other libraries can be easily swapped in (i.e. SQLObject instead of SQLAlchemy, Genshi instead of Mako) and is strictly WSGI compliant making middleware insertion easy.

I used Pylons over Django since it was highly compartmentalised. I wanted to access the data in the web-app using a desktop application. I just imported the SQLAlchemy library into my desktop app and worked with it exactly as I would in the web-app.

Turbogears 2.0 will actually be written on top of the Pylons framwork.

Answer 4

Full-stack frameworks

Django, TurboGears, and Pylons mostly have the feel of Lego blocks, where different apps can be used in different websites very easily, all using the prescribed tools for the database, network, etc. If you like any of the apps currently in development (say, Byteflow, Sphene Community Tools, or Flatpages for Django), then there's not really much work to do.

Of the three, Django was the first I tried, and I went insane looking for the most trivial of things, like code for the URL of the page that was being rendered. Django is well polished and it has good documentation, but it doesn't like letting you reach down to a lower level of abstraction. It's also accused of being monolithic and having an NIH attitude, although it's becoming more and more modular.

TurboGears is written over CherryPy, Pylons is written over Paste, and TurboGears 2 is being written over Pylons. Pylons and TurboGears have very similar philosophies: for the most part, they claim to use "best-of-breed" libraries. However, they were initially developed at different times, and the state of Python libraries changed considerably in between. Thus, both frameworks essentially provide glue around solid libraries, but they use different toolsets at for pretty much everything. A brief overview:

• TurboGears - CherryPy for HTTP, Genshi (XML-based) for templating, SqlObject (simpler) for persistence
• Pylons - Paste for HTTP, Mako (faster) for templating, SqlAlchemy (more powerful) for persistence

Paste and Pylons are architected entirely around WSGI. WSGI (links: Wikipedia, PEP 333, WSGI wiki is a low-level interface, essentially a powerful superset of CGI and its brethren. While most people acknowledge its usefulness to framework developers, there's a lot of controversy over its usefulness to webapp developers, which I won't link to here.

Of the two, Pylons is probably the better choice because it offers more modern components. The TurboGears community was divided a while ago; I'm not sure how they're doing right now, but it'll still be chaotic until the transition to TurboGears 2.

HTTP frameworks

CherryPy, Paste, and maybe web.py do lots of networking for you but little else. If you want to use Jinja2, Genshi, Mako, Cheetah, or any other templating engine, you'll have to integrate it yourself. And if you want to use SqlAlchemy, Storm, SqlObject, or Dejavu for databases, you'll have to integrate them yourself. The benefit is that the low-level data is right in front of you. For example, in CherryPy, getting the base of the URL, the list of cookies, and the list of headers is as simple as

cherrypy.request.base
cherrypy.request.cookie
cherrypy.request.headers

because CherryPy is so pythonic. The request is just an object that has all those attributes. Similarly, response is an object so you can set the client's cookies with statements like

cherrypy.response.cookie['cookieName'] = 'cookieValue'
cherrypy.response.cookie['cookieName']['expires'] = 3600

Paste (which I haven't used outside of Pylons) is slower and less pythonic, but it uses WSGI exclusively and is currently gaining momentum. The WSGI wars have simmered since CherryPy 3 was released in late 2006, adding better WSGI support; but the two design philosophies are still polar opposites.

Other frameworks

There's also Zope, the heavy-duty grandfather of Python frameworks, and Plone, a content management system that runs on top of it. I haven't used either one, but Zope is generally compared to Java web frameworks – good if you're looking for a reliable platform, but not so good for rapid development. Zope 3 has tremendously reduced the learning curve, but most Pythoneers have probably moved on.

There's also Twisted, a lower-level framework and server setup, and Nevow, another layer over Twisted. I don't know enough about them to say much more, though.

There really are a lot of great choices out there; for the vast majority of users, Django, Pylons, and CherryPy offer the best coverage, and I find myself going back and forth between them for each project. My personal preference is a custom setup with CherryPy, simply because I don't like the hierarchy and opaqueness that full-stack frameworks try to enforce. For you, CherryPy sounds like a good bet, too.

Answer 5

For the no-frills web-framework I would choose CherryPy. Its a simple out of the box application server and with very little configuration (mod_proxy) you can put it behind apache into a production website.

Answer 6

Well, there's a reason for the fact that there is no obvious choice for a python web framework. There are quite a few, as the other guys pointed out, and none of them seem to prevail. There was some interesting project called Tesla, which worked pretty well, and had additional features that pylons miss (migrations etc.), but seems unmaintained.

Even though I would agree, that the best thing for your situation would be pylons, it definitely is not the easiest frameworks to learn. There is quite a learning curve to pylons, as there is to django by the way. But, since pylons has all the rails helpers ported, I would suggest you should also check Rails and maybe merb (both written in Ruby), as they might give you (especially rails) an easy introduction to the web frameworks and sort of "feel" of what it is to the framework, what to expect, what's cool and so on. Anyhow, what I feel with Python web framework is that there is a pethora of choices (template systems, ORMs and so on) and the user, who has just heard of web frameworks gets lost in translation. There's just to much to choose from.

I also prefer Python over Ruby, but when web frameworks are concerned I have to give to DHH - Rails framework simply rocks as far as developing code is concerned.

Answer 7

I've used both web.py and pylons, and prefer pylons. Web.py was probably a little bit nicer, and lighter weight, but that was also its achilles heel. I had a very hard time getting it installed and running properly on a server. I switched to pylons, and found it to be a little better documented. I was able to get a pretty functional photo blog up and running on it quickly. I am having an issue with it though.

Answer 8

I have begun to hate Turbogears for the problems I faced with SQLAlchemy. TG 1.0 by default supported SQLObject and then 1.1 (i think) had additional support for SA. But the way things are set up in TG for the DB access (the engine) - I still don't get it fully.

But overall it is a good framework - especially since we are using Flex as the View. We just expose off the methods and all the output comes out as JSON. No need to do any work. Just a simple decorator.

But overall I would use Django only for sites which require a CMSish interface. Other wise I would goto pylons, but I couldn't get some DB and user auth working in that too. But reddit is powered by pylons.

I use web.py for some really simple sites or sites which I need to run on my desktop - like a simple todo list.

Answer 9

I personally found CherryPy to be the easiest to work with off the bat - it stays out of your way, and if you use python a lot, it will feel very natural (at least it did for me). I've found it's code easy to read as well, which is a major plus for me- although not too uncommon with python apps.

I've found it the easiest for me to scale from concept to full application, as far as web development goes. You don't have to worry about anything like what directory the framework wants you to put your files in by default, the configuration is straightforward, you handle templating and such however you want to. It's made the process of adding abstraction where needed in web-apps when it's needed much simpler for me, as I know where everything my app is doing is right off the bat.

(shameless plug: If you want an example of a web-app written in CherryPy, I have one here that sends Ubuntu packages and their dependencies to the user as a tarfile. It's probably not a shining example of great code, but it's ~150 lines of python plus a little HTML and such at this point in time and does something useful).

Answer 10

I looked at Turbogears, Pylons and Django too. Django seems to fit better with how I think and that is what set it apart from the others. Even contrasting it to other frameworks I've used outside of python like Rails or ASP.Net - I get more done quickly with Django. Deployment has been easy as well. Setting up a production ubuntu box at slicehost for Django and deploying an app takes very little time.

I say write a small sample app in all three and see which one feels right for you.

Answer 11

This isn't a great answer, but I would say avoid Zope and especially Plone (which runs on it). Zope has a horrible mixture of data and code in it's database - the ZODB. While the ZODB could be a nice place to persist python objects, it's not good to build your whole site's templates and code in the same URL namespace as user data you are storing.

You can move code out of the ZODB and into the filesystem, but it still has to resiide in the URL space of the ZODB - you always need a hook in the ZODB that tells it where your code is, rather than the other way around.

The other problem with Plone is that if you start it out of the box in debug mode, it throws loads of deprecation warnings on itself. This is an indication that the underlying APIs and system were not well designed, and are continuously being overhauled.

You might find a useful feature, like versions (kind of svn branching inside the ZODB), ZClasses (let you create a class of object in the ZODB without developing an add on product), DTML (a template markup system that makes documents that resemble XML but don't validate) or even the find tab in the main interface, and when you ask on the mailing list about a problem you are having, the response is "That area is deprecated". But it doesn't give big deprecation warnings when you try to use them.

Answer 12

Sorry if this doesn't directly answer your question, but the previous comment was so full of factual errors that I can't let it go unanswered.

This isn't a great answer, but I would say avoid Zope and especially Plone (which runs on it). Zope has a horrible mixture of data and code in it's database - the ZODB. While the ZODB could be a nice place to persist python objects, it's not good to build your whole site's templates and code in the same URL namespace as user data you are storing.

This is not how people build Plone sites, and hasn't been for a long time (since Plone 2.0, years and years ago). Code lives on the file system, content lives in the database. It's still possible to put code in the database if you absolutely need it, but it is strongly discouraged.

You can move code out of the ZODB and into the filesystem, but it still has to resiide in the URL space of the ZODB - you always need a hook in the ZODB that tells it where your code is, rather than the other way around.

No, you don't. This is wrong. The "hook" is on the file system.

The other problem with Plone is that if you start it out of the box in debug mode, it throws loads of deprecation warnings on itself. This is an indication that the underlying APIs and system were not well designed, and are continuously being overhauled.

Uh, no. This is an indication that the project is doing responsible evolution of the code base. All code evolves, and you want to see what methods are no longer the best way to do things. Plone hasn't thrown deprecation warnings about itself since Plone 2.5 — and then it was done because it supported two different versions of the underlying Zope architecture (Zope 2.8 and 2.9) at the same time.

If you have spent any time in a serious, stable, software project, you'll know that deprecation is inevitable. Plone handles it in a responsible manner, supporting the old code for two releases (while throwing deprecation warnings), and removes it in the third release. Plone is 8 years old, and constantly evolving to be better.

You might find a useful feature, like versions (kind of svn branching inside the ZODB), ZClasses (let you create a class of object in the ZODB without developing an add on product), DTML (a template markup system that makes documents that resemble XML but don't validate) or even the find tab in the main interface, and when you ask on the mailing list about a problem you are having, the response is "That area is deprecated". But it doesn't give big deprecation warnings when you try to use them.

You're confusing concepts here. These things aren't deprecated, they are just not used by Plone. They work fine for Zope, and the only reason why we tell you to not use them is because there are better ways to do all of them. In order:

• Versions — Plone has a better versioning system included with Plone 3.0 and later.
• ZClasses — Archetypes and Dexterity are both better and more powerful.
• DTML — this isn't deprecated, and we use it for non-XML like data.
• Find tab — I have no idea why you think this is unsupported / not working. I use it every day.

In sum, it seems like you used Plone years and years ago, got confused, and gave up. Plone has evolved a lot the past 4 years, and the complaints you post here are simply not true anymore (if they ever were).

— Alexander Limi, Plone co-founder

Answer 13

While I'd like to have a nice rich framework to use, I would prefer a framework that was accessible rather than one that "did a lot of code for me". Mainly because if I then need to customise something, I need to get involved in a lot of that boilerplate code.

Under that premise I, like some other people, would recommend you to look at CherryPy. CherryPy is a fairly mature and lightweight application server, many "full stack frameworks" (most known: TurboGears, Pylons) build on it.

CherryPy roughly compares to TurboGears/Pylons like Tomcat compares to Seam/RIFE/Wicket in the java world. It abstracts away all the nitty gritty HTTP-details from you and provides you with a clean API to implement your Page-Controllers against. How clean? That clean:

import cherrypy

class HelloWorld:
    def index(self):
        return "Hello world!"
    index.exposed = True

cherrypy.quickstart(HelloWorld())

That was a complete CP application, you can run it and see it in your browser.

CP, being lean and mean as it is, expects you to know what you're doing to some degree. Out of the box it does not come with a templating engine but it's easy to integrate with one of the many excellent choices. It doesn't get in your way with any kind of pre-decided database abstraction either but will happily work with whatever method of persistence you prefer.

In short: CP is not a turnkey-solution, it's a building block.

A weak spot about CherryPy is the documentation, it's unfortunately quite spotty and outdated in many areas which can be a hinderance to newbies. But the good news is that, since it is such a simple and pythonic design, you won't need the documentation much after the initial learning phase. Furthermore CP backed by an active community that will generally be friendly and helpful towards confused newbies, on the mailing list and on IRC (#cherrypy on OFTC).

Probably the most important selling point of bare CP over the more featured "full stack frameworks" (django, TurboGears, Pylons) is that you'll actually be writing your application in python, not in a suite of framework-specific APIs, annotations and semantics. With CP you're free to model your application in any way you like without the constraints and "mandatory best practices" that those bigger frameworks impose on you.

Answer 14

You may want to try web2py (it manage session, cookies, request, response, cache, internationalization, errors/tickets, database abstraction for GAE, SQLite, MSSQL, MySQL, Postgres, Oracle, FireBird, etc.) It does not need installation - just unzip and click on it - and you can do development in your browser.

Here is a complete app that counts your visits and provides internationalization (T):

def index():
    session.c=session.c+1 if session.c else 1
    return dict(message=T("Hello (counter=%s)",session.c))

It uses a default generic view but can optionally define your own:

{{extend 'layout.html'}}
<h1>{{=message}}</h1>

Answer 15

I ran into this same dilemma recently and wrote up a blog post on the decision process: http://stackq.com/blog/?p=46

Basically, depending on your needs for flexibility (e.g. would you be OK running the framework out of the box?). If you're OK with running something vanilla out of the box, Django is definitely a good choice - plus they have good community support and documentation to boot.

However, if you're going to be doing some customization (which in our case we were), then TurboGears/Pylons is a much better choice. These frameworks are built so you can swap components relatively painlessly. We ended up going with Pylons because of a few minor details (paste, mako, and routes), but the two are very similar.

Answer 16

Python

zope2 + CMS = plone < Zope3 + CMS = Z3Ext

(http://z3ext.net/)

Answer 17

I dream of a Grails like in python
Grok is close from that but still confusing

Answer 18

Try Karrigell or Web2Py (Full Stack) Frameworks

Answer 19

There is also a relatively recent framework which is pretty minimal called Flask. I have not tried it but it looks pretty nice.

Answer 20

The best python web framework I've used is Flask. The documentation is amazing. It covers all sorts of things you might want to do with the framework. This author must have learned many lessons from other web frameworks. It has integration guides for SQLAlchemy and MongoDB and covers several ways to use them. It's built on Werkzeug, which gets a lot of things right, and it includes the same epic debugger you may know from Pylons. Url routing works with simple decorators. It has Pylons' threadlocal variables for convenience. Overall, I find it's quite simple and doesn't get in the way of my python programming.