[Fixed]-Turbogears 2 vs Django – any advice on choosing replacement for Turbogears 1?

TG2 is built on top of Pylons which has a fairly large community as well. TG got faster compared to TG1 and it includes a per-method (not just web pages) caching engine.
I think it’s more AJAX-friendly than Django by the way pages can be easly published in HTML or JSON .

2011 update: after 3 years of bloated frameworks I’m an happy user of http://bottlepy.org/

I have been using Django for a year now and when I started I had no experience of Python or Django and found it very intuitive to use.

I have created a number of hobbyist Google App Engine apps using Django with the latest one being a CMS for my site. Using Django has meant that I have been able to code a lot quicker and with a lot less bugs.

Am sure you would have read from plenty of comparison between TurboGears and DJango on web.

But as for your temptation on CMS and GAE, i can really think you got to go DJango way.
Check these out, and decide youself.

Django with GAE

Django for CMS

Ive only got one question…is the app you are developing directed towards social networking
or customized business logic?

I personally find Django is good for social networking and pylons/turbogears if you really
want the flexibility and no boundaries…

just my 2c

TG2 seem much complicated and confusing, even for doing somewhat simple like a login page with multimple error messages
How to extend the Turbogears 2.1 login functionality
I think thats because of intemperance in modularity…

Django ORM uses the active record implementation – you’ll see this implementation in most ORMs. Basically what it means is that each row in the database is directly mapped to an object in the code and vice versa. ORM frameworks such as Django won’t require predefining the schema to use the properties in the code. You just use them, as the framework can ‘understand’ the structure by looking at the database schema. Also, you can just save the record to the database, as it’s mapped to a specific row in the table.

SQLAlchemy uses the Data Mapper implementation – When using this kind of implementation, there is a separation between the database structure and the objects structure (they are not 1:1 as in the Active Record implementation). In most cases, you’ll have to use another persistence layer to keep interact with the database (for example, to save the object). So you can’t just call the save() method as you can when using the Active Record implementation (which is a con) but on the other hand, you code doesn’t have to know the entire relational structure in the database to function, as there is no direct relationship between the code and the database.

So which of them wins this battle? None. It depends on what you’re trying to accomplish. It’s my believe that if your application is a mostly a CRUD (Create, Read, Update, Delete) application which no hard and complex rules to apply on the relationships between the different data entities, you should use the Active Record implementation (Django). It will allow you to easily and quickly set up an MVP for your product, without any hassle. If you have a lot of “business rules” and restrictions in your applications, you might be better with the Data Mapper model, as it won’t tie you up and force you to think strictly as Active Record does.