Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Web Development with TurboGears and Python

timothy posted more than 8 years ago | from the automagic-integration dept.


rdelon writes "TurboGears was previously mentioned here as "Python on Rails". It has since made tremendous progress and is now a popular Python web MVC framework (along with Django). IBM developerWorks just published a great article about TurboGears and a book is on the way. Unlike Rails and Django, TurboGears is made up of several pre-existing subprojects. One of the great features of TurboGears is the 'toolbox,' which allows you to configure and check various aspects of your application and database in a browser."

cancel ×


Sorry! There are no comments related to the filter you selected.

It's a two-part series (4, Informative)

aymanh (892834) | more than 8 years ago | (#15713311)

Excellent! For those who (like me) can't decide which Python web framework to pick and learn, this is a two-part series on both Django [] and TurboGears from IBM, one can learn the basics of each one and decide.

Guido prefers Django (4, Interesting)

YA_Python_dev (885173) | more than 8 years ago | (#15713591)

FYI Guido van Rossum [] prefers Django [] (from his blog [] ).

And people that use web frameworks in Python [] will probably be interested in WSGI 1.0 [] (the Python Web Server Gateway Interface) that will be added to the standard library in Python 2.5: it will probably be supported by all the major Python web frameworks.

Re:Guido prefers Django (3, Interesting)

masklinn (823351) | more than 8 years ago | (#15714310)

Well, that can be understood, Turbogears for example is mostly "just another python framework" and a Rails ported to Python. If you want Rails, just use Rails (Ruby isn't hard to graps if you know Python... hell, it's even easy, just as switching from Ruby to Python is easy, once you overcome the minor differences)

Django on the other hand offers a slightly different approach of the notion of web frameworks, and has the killer "Hey let's just give you complete administrator interfaces in like 2 lines" which is a true life saver (and the "default" admin interfaces look quite nice too, much nicer than anything i'd be able to code without a designer anyway)

Re:Guido prefers Django (1)

jma05 (897351) | more than 8 years ago | (#15714570)

> FYI Guido van Rossum prefers Django

Guido is a language designer, not a web developer. What he prefers has absolutely no bearing considering that he was asking the community to teach him web frameworks 6 months ago. 146149 []

Re:Guido prefers Django (says who?) (2, Insightful)

SimHacker (180785) | more than 8 years ago | (#15715607)

How did you get from Guido's statement that "Django's gaining steam" to your statement that "Guido prefers Django"? Prefers it over what? Is that from your personal communication with him, something he said in public somewhere else, or are you reading something into that blog posting that I can't see? He doesn't mention anything about TurboGears or his preference in web frameworks, he simply states that Django is gaining steam in a big way. You're jumping to conclusions if you think that blog posting implies that he preferrs one web framework over another.

I'd be interested to know what Guido thinks of Zope, since he worked for Zope corporation in the past. And what he thinks of Zope Page Templates, since he worked on that code.


Re:Guido prefers Django (says who?) (1)

sholden (12227) | more than 8 years ago | (#15715856)

I took a brief look at Django, and while I like their website (pretty and easily navigable and chockfull of useful information), I'm not keen on the particular tools they provide (it doesn't help that they begin every example with "from mumble.something import *").
""" - 146149 []

doesn't sound like he likes it much either...

Re:Guido prefers Django (says who?) (1)

Gumber (17306) | more than 8 years ago | (#15729669)

That complaint was leveled before a major refactoring to "remove the magic" from Djago was merged with the codebase.

Guido says he doesn't endorse any web framework. (4, Informative)

SimHacker (180785) | more than 8 years ago | (#15717040)

Guide van Rossum writes [] :

Re: Which was chosen?
Posted: Apr 21, 2006 6:46 AM

I'm using Django templates and am very happy with them. I've not had time to compare and contrast it to other frameworks, or even to try out other parts of Django. I do have to say that I am very happy with the way the Django project is being managed; they seem to really "get" open source community projects. I also like WSGI and Phillip Eby's wsgiref implementation, which has been made a part of Python 2.5.

I've decided not to officially endorse a particular web framework; it would be way too big a responsibility. I do recommend that web developers (I'm still not much of one) get together, share experiences, and ask the web framework developers to standardize low-level APIs in additionn to WSGI (PEP 333). Also, I recommend setting up a wiki page where web frameworks are compared and contrasted, as a service to prospective users.

So no, he doesn't prefer Django. It's official: he makes no endorsement whatsoever, except for the low level WSGI standard. He's using Django for at least one application, but he encourages people to compare and contrast all web frameworks.


nice (0)

Anonymous Coward | more than 8 years ago | (#15713358)

that's awesome

slashdotted already (-1)

Anonymous Coward | more than 8 years ago | (#15713369)

maybe those turbogears need oiling...

TurboGears is great, and so is Django (4, Informative)

Ursus Maximus (540370) | more than 8 years ago | (#15713370)

Both TurboGears and Django are excellent. Furthermore, each has strengths for different kinds of projects, with TurboGears at its best for web applications and Django for big, industrial strength web content sites. Twisted and Zope are great too, but for most developers, Django or TurboGears is going to suit them best. Both are under rapid, well coordinated development and are proven solutions that will scale well over time. TurboGears' best of breed component approach is, in my opinion, a winning strategy, especially in the Python community since Python is blessed with so many great projects (some people think too many projects), giving a plethora of high quality, well maintained and best of breed components for TurboGears to choose amongst. There are multiple good tutorials on both frameworks here, [] , as well as related podcast material about TurboGears and related Python material.

+1 funny (0)

Anonymous Coward | more than 8 years ago | (#15714205)

Good job on the PHB marketdroid post. Always nice to be able to play buzzword bingo while reading slashdot.

Community Oriented (3, Insightful)

amcnabb (682951) | more than 8 years ago | (#15713399)

The article was interesting, but I disagree with their claim that, "TurboGears is more community-driven than Django because it was built with pre-existing, open source components." From everything I've seen, Django has a strong community behind it. I don't think I've ever seen an open-source project whose maintainer is as helpful to users and contributors than Adrian Holovaty is. He's extremely respectful and responds quickly to bug reports and suggestions. In addition to its clean, unified feel, the community is one of the main reasons I was attracted to Django.

Re:Community Oriented (2, Informative)

Senzei (791599) | more than 8 years ago | (#15713483)

As a counterpoint from someone who uses TurboGears, I would say that their community is in about the same state. Generally at least one the TG devs is able to handle issues with a given component, and if not there is an entire community dedicated to just that platform. Ultimately I see the TurboGears design philosophy as an extension of the unix "do one thing well" mentality. The usefulness and applicability of this in web development is a matter of personal opinion, but I think it still holds well.

Ultimately though there is enough room in the Python world for a few different web dev stacks. Django and TurboGears both focus on slightly different problem spaces. Django seems more CMS-oriented while TG is better at web apps; obviously this is speaking in generalities, they are both useful for either.

Indeed (0)

Anonymous Coward | more than 8 years ago | (#15717383)

Indeed. Turbo gears is not a project. The guy took (the best of) four other projects and made a stack. He did not write any code. The developers of the four other projects are supposed to support TG because it uses their project. This is a matter of a political aliance/merger thing.

In its web page it sais: """The TurboGears Project Philosophy is all about building on the work of great open source projects, not replacing or supplanting them.""". But Turbogears is itself replacing the work of Pylons, Subway, Django, Plone and a few other millions of OPEN SOURCE web frameworks written in python. The advantage of TG compared to the others is that TG uses four python projects and has got their support (except from Cheetah who don't kiss ass). But it is supplanting hard work of others with zero code.

And following the classical scum where thei create a mailing list with 1500 fake members and posting messages from very excited users with fake accounts, their are trying to overcome the threshhold, and be in the top 3, and profit.

The article says... (1)

xxxJonBoyxxx (565205) | more than 8 years ago | (#15713435)

"Toolbox is geared toward developers, not end-users, and is best used for aiding in data modelling and bootstrapping your application with data."

In other words, if you have any other way to work with data in a database, you don't need "Toolbox".

"A side benefit of the TurboGears framework is that it is a megaproject with a megacommunity. TG has become a powerful, central force, driving interest and involvement into the core components that make up TurboGears. It is the tide that raises all ships."

Sounds like the author has a hard** for TurboGears. Comparison shoppers beware...

Re:The article says... (0)

Anonymous Coward | more than 8 years ago | (#15713486)

>Sounds like the author has a hard** for TurboGears.

A pointer to a pointer to a hard? That doesn't make sense.

Re:The article says... (1)

ciw42 (820892) | more than 8 years ago | (#15713489)

People don't tend to get genuinely enthusiastic about such thing unless there's a good reason, and I have to say that I have a similar level of enthusiasm for Python, although it's much less sexual than you are suggesting.

I've no need for such a framework myself, but out of general curiosity I've had a good look at what it offers, and it does indeed appear to be a good fit to make light work of some very common web application development requirements.

Re:The article says... (1)

masklinn (823351) | more than 8 years ago | (#15714332)

People don't tend to get genuinely enthusiastic about such thing unless there's a good reason

Oh yeah? Last time I checked there were still people genuinely enthusiastic about Java, and there won't be any reason to be enthusiastic about Java until Sun officially announce that they're deprecating it. Or that they're implementing C#3.0 leve functionalities (minus the stupid XML and SQL shintegration).

Oh wait, there is already a JVM language with some of that stuff, it's called Nice, how about just replacing java with Nice?

Re:The article says... (1)

Senzei (791599) | more than 8 years ago | (#15713532)

"Toolbox is geared toward developers, not end-users, and is best used for aiding in data modelling and bootstrapping your application with data."

In other words, if you have any other way to work with data in a database, you don't need "Toolbox".

Actually the in other words statement is: "It was not made to be an interface for your users, don't try to make it work as one." The toolbox is a good intermediate option between building initial configuration into your app and doing it directly via raw database access. For instance it is useful when setting up initial administrator accounts within the system.
"A side benefit of the TurboGears framework is that it is a megaproject with a megacommunity. TG has become a powerful, central force, driving interest and involvement into the core components that make up TurboGears. It is the tide that raises all ships."

Sounds like the author has a hard** for TurboGears. Comparison shoppers beware...

Although the megaframework statements get out of hand, the sentiment is still pretty much correct. It does increase interest in the projects for the core components and has led to patches, improvements, and new developers for those projects. Yeah, the guy did go over the top on that one, but being a nut does not inherently make you wrong.

Re:The article says... (0)

Anonymous Coward | more than 8 years ago | (#15713828)

What the hell? You can say "hardon" on Slashdot, you know. Why are you even censoring yourself? That's about the least offensive thing I've ever seen anybody censor. Fuck it! Just say what you want. If you don't want to say it, then find another word. You're just making yourself look like a uptight moron.

slashdot meets the real world (3, Funny)

Anonymous Coward | more than 8 years ago | (#15713548)

Just the other day in the Ruby for Rails review thread, someone was saying:

Soon to be obsoleted by Airways for Python

Guido Van Rossum heard exclaiming that he was developing with SNAKES on a PLANE

Python to Ruby (2, Informative)

Boone^ (151057) | more than 8 years ago | (#15713684)

I've been using Python for scripting glue at work for about a year now, but I recently had a small side project come up that was better served having a web interface to a database. Like everyone else, I downloaded/installed Rails. I had given Django a peek, but given that this is a side project, I didn't have the time nor energy to keep up with a rapidly developing platform. Django's website cautions about framework upgrades until 1.0 when the base API will be locked, so I went with Rails. Other than learning yet-another-scripting-language, using Rails (without even really understanding it) hasn't been much of an issue.

Choice is both good and bad, in my opinion. It sounds like TurboGears and Django specialize in different things, when it would be preferred for occasional users like myself that there were one clear winner that was evangelized and well supported for all applications. Perhaps out of this competition this will happen for both platforms -- this is where choice is good!

Re:Python to Ruby (1)

Black Perl (12686) | more than 8 years ago | (#15714216)

Do you feel you've made the right choice?

I, too, am looking to use one of the three frameworks you mention. I gave up on Catalyst--it's neat, but changing too fast for me. So I figure I'm going to be learning another language and framework at the same time. The recent slashdot review of the Ruby-for-Rails book tips the scales a bit toward RoR, mostly because I feel I could get productive faster. Would you agree?

Re:Python to Ruby (1)

aceydacey (973258) | more than 8 years ago | (#15714797)

Well, if you use Unicode then either Python based framework would probably be btter. Also, there are in general a lot more tools and libraries to help you on your way with Python coding than with Ruby coding.

Re:Python to Ruby (1)

graznar (537071) | more than 8 years ago | (#15715231)

Well, if you use Unicode then either Python based framework would probably be btter. Also, there are in general a lot more tools and libraries to help you on your way with Python coding than with Ruby coding.

Probably (depending on what you're doing), but there is an extreme lack of plugins/extensions/whatever for Django and TurboGears when compared with Rails.

Template system (0)

Anonymous Coward | more than 8 years ago | (#15713798)

It looks impressive, but the template system seems a lot more complicated do deal with than ERb in Ruby on Rails.

AJAX support.. (1)

swtaarrs (640506) | more than 8 years ago | (#15713892)

I watched the 20 minute wiki video and the biggest thing I noticed was that the AJAX page list took a LOT more code than the same functionality would in RoR. Other than that it looks nice, and it's good that RoR has some real competition.

Pylons: In-between RoR and Turbogears (1)

polyhue (38042) | more than 8 years ago | (#15714198)

Sort of in-between the two is [yet] another Python project, Pylons [] . Borrows from Rails most heavily in controller/routing/helper(prototype/scriptaculous) areas, and it's extremely flexible, supports whatever DB layer you want, template layer, and URL dispatch. It heavily uses WSGI [] but you can ignore that fact if you don't need or want to bother with it to start. It runs on top of Myghty which is a python port of Mason(perl) and runs some heavy sites like

SqlAlchemy (3, Interesting)

novitk (38381) | more than 8 years ago | (#15714651)

One excellent Python project that doesn't get enough publicity is my favorite ORM tool by Michael Bayer - SqlAlchemy [] . Think Rail's ActiveRecord with Hibernate power.

There was some talk of integrating it with TurboGears to create some competition for SqlObject. Not sure where this stands currently.

Re:SqlAlchemy (1)

Richard Jones (28382) | more than 8 years ago | (#15715504)

"Not sure where this stands currently."

Kevin Dangoor did his EuroPython 20-minute challenge using TG and SQLAlchemy, and he can't stop talking about how much SQLAlchemy kicks SQLObject's ass :)

License? (2, Insightful)

nurb432 (527695) | more than 8 years ago | (#15714879)

From a quick glance it wasnt apparent how this is licensed.

Re:License? (2, Informative)

Patrick Lewis (30844) | more than 8 years ago | (#15715828)

The main TurboGears stuff is MIT licensed. Various components have their own (open source) licenses. LGPL (SQLObject) is the most restrictive one, but that can be swapped out with SQLAlchemy (MIT), if necessary. []

No GUI builder? (1)

nurb432 (527695) | more than 8 years ago | (#15715205)


Rails is not ONE package (1)

hotgazpacho (573639) | more than 8 years ago | (#15715229)

> Unlike Rails and Django, TurboGears is made up of several pre-existing subprojects.

You mean like Rake, ActiveSupport, ActiveRecord, ActionPack, ActionMailer, and ActionWebService?

$ gem dependency rails
Gem rails-1.1.4
    rake (>= 0.7.1)
    activesupport (= 1.3.1)
    activerecord (= 1.14.3)
    actionpack (= 1.12.3)
    actionmailer (= 1.2.3)
    actionwebservice (= 1.1.4)

Re:Rails is not ONE package (1)

afd8856 (700296) | more than 8 years ago | (#15720347)

I think you overlooked the "pre" from pre-existing.

Podcast with Django's Adrian Holovaty (3, Interesting)

muchawi (124898) | more than 8 years ago | (#15715285)

In an attempt to combine all the best of web frameworks into one event, I interviewed Adrian Holovaty of Django on the Ruby on Rails podcast: Adrian Holovaty on the Rails Podcast [] He's a smart programmer and it helps to see the different philosophies behind the way popular web frameworks were constructed.

New Turbogears features (2, Informative)

fforw (116415) | more than 8 years ago | (#15716131)

While the article mentions Catwalk (toolbox app to set up initial database objects) it does not mention some of the very nice new features in Turbogears 0.9a6 [] (supposed to be real close to 1.0 now):

  • Identity Management
    The turbogears quickstart can now create a set of customizable standard classes to handle standard authentication and authorization. A User Group Permission model coming with easy-to-use identity decorators for exposed methods. ( Identity Management Documentation [] )
  • Widgets / Forms
    A system to create reusable Form Widgets (with optional scripting / styles) and to use them in forms -- including support for error display and data retention.
  • Internationalization support
  • Optional support for SQLAlchemy instead of SQLObject
The newly added toolbox offers the following tools:
  • Catwalk (mentioned in the article)
    Database tool meant to ease the creation of initial data. Sure, you can always just use plain SQL to set them up, but managing relations between tables can be slow and bothersome, especially for N-to-M relations (RelatedJoins in SQLObject terms)
  • Model Designer
    Toolbox tool helping to design your models. (Showing diagrams etc)
  • Web based python console
  • Widget Browser
    Allows browsing through all available Widgets with working examples, example code and configuration help
  • admi18n localization tool
    Tool to collect internationalized strings and create new language catalogs

I started playing around with Turbogears some time ago and like it very much. The documentation is a bit thin at times, but the source code is easy to read and accessible (using ipython to interactively explore things also helped a lot.) I implemented my blog [] in python and had only minor problems. And the code size also turned out to be relatively small.. For the metrics fetishists:

Blog with tagging, User handling (subscription, email confirmation etc), Image handling (upload, admin, thumbnails), atom feeds (general + tag based feeds) plus some minor things:

  • python code : 1181 lines, 40762 bytes
  • kid templates : 610 lines, 21200 bytes
plus some style sheets, javascript code and images..

Turbogears & SQLAlchemy (2, Interesting)

fbg111 (529550) | more than 8 years ago | (#15717017)

One of the most appealing aspects of Turbogears imho is the work to supersede the db layer, currently SQLObject, with SQLAlchemy [] . The problem with most web frameworks is that their ORM db layers treat the db as just an object store, rather than as a relational database. This works for relatively simple 37signals-esque websites, but not for more complicated sites that require a relational algebra engine, for example any relativley complicated web-based BI application or booking engine. For example, one of the fundamental features of the relational model is that the result of any query against a table or number of tables is another table. In that respect, SQLAlchemy lets you map classes not just to tables, but also to joins, unions, and subqueries (which are themselves tables). Turbogears is the only framework I know of so far that is attempting to integrate SQLAlchemy. They're still in the relatively early stages [] of the integration, it seems, but are working to provide an easy migration from SQLObject to SQLAlchemy when the latter is ready, making TurboGears top on my list of webframeworks to consider/recommend for new projects.

Quite happy with TurboGears and Kid (1)

SimHacker (180785) | more than 8 years ago | (#15721019)

I've just completed a large project using TurboGears, and I'm quite happy with it, considering how new it is (not even to version 1.0 yet).

The Kid templating system is wonderful and well designed: very Pythonic, XML centric, practical and easy to use. But it's pretty hard to trace and debug problems with templates, and it's not very smart about stripping out unnecessary white space (not a big deal, but the Kid compiler could be smarter about optimization, and inject extra information to make debugging easier).

So many other template systems attempt to fight against Python or XML, and end up with a big mess that tries to reinvent the wheel and ends up with something much worse than the sum of its parts. But Kid is straightforward and honest with Python and XML. You don't need to learn another weird half baked language.

I've done a lot of work with Zope and Plone, and I'm sick and tired of Zope's sloppy DTML, awkward TAL, inexplicable METAL, casterated "secure" python scripts, brittle SQL methods, insane acquisition, unidentified flying object models, and all of Plone's fractal complexity and self perpetuating bureaucracy, so Kid is a refreshing breath of fresh air.

I was already using SQLObject before I started using TurboGears (which was one reason I found it so easy to switch to TurboGears). I like it, and it works well for my current purposes, but I'm interested in learning more about SQLAlchemy, and maybe using it with more complex projects.

The project I just finished has about 12,000 lines of Python code, and it's quite template-heavy: about 300 templates, comprising more than 32,700 lines, almost a megabyte of XML Kid template source code. I consider the kid template content to be the crown jewels of the project, just as important as any of the Python source code, so it's all nicely indented and easy to read and maintain, like Python code. There's no place for sloppy templates, just as there's no place for sloppy code.

The idea that a templating system should't allow you to write any code is just as foolish as the idea that the templating system should invent a totally new programming language. I'm already quite happy with XML and Python, and have invested a lot in learning them and their associated tools, and I don't need to be protected from myself. Python and XML are both well designed and universally supported, so I have no need for a templating system that doesn't let me use the full power of Python, along with with the pure standard syntax of XML.


my take (0)

Anonymous Coward | more than 8 years ago | (#15723660)

I don't do web stuff for a living but I recently had to do a little bit.

I looked at and discarded both django* and turbogears**. Furthermore, I'd screwed around with Zope before and it's all expenses paid trip to the land of most surprise isn't my thing.

I guess I'm fuckall lame because I bailed and wrote some small python cgis with sqlite and, after downloading and comparing numerous python template engines, a small, stupendously-elegant, and boringly-named library written by Terrence Parr (

With all that said, if Django and Turbogears were my only choices. I'd grudgingly choose django for its consistency. While django at least feels like a product, turbogears is more like your puke after lunch at an Ethiopian restaurant.

*I had install problems, the tutorial was broken, and it was just damn unintuitive.

**all the consistency and cleanliness of perl (installation dependencies dump turds all over your system) with the conceptual elegance of a bash script running on cygwin.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>