TurboGears: Python on Rails?

gcantallopsr writes "If you liked Ruby on Rails and its 15m intro video (.mov) you will probably like TurboGears and its 20 minute wiki tutorial. (.mov) It shows you the development of a simple wiki in just 20 minutes, and there is a text version of the tutorial. TurboGears uses Python, SQLObject, CherryPy, Kid, MochiKit and some extra pythonic glue to help you to (in their own words) 'Create a database-driven, ready-to-extend application in minutes. All with designer friendly templates, easy AJAX on the browser side and on the server side, not a single SQL query in sight with code that is as natural as writing a function.'"

What is natural about that?

[barcodez]

as natural as writing a function.

So what is so natural about writing a function? I would have though if it is based on Python it would be OO with behavioral methods rather than procedural function calls.

Why is everyone clambering to find the 'next' language for programming in the small when quite clearly a good language for programming in the large is what is required - at least for enterprise applications (I'm going to include wikis in that for now).

Re:Does it scale?

[Anonymous Coward]

Bullshit. J2EE is all about hype, the latest buzzword that clueless managers will use whenever a new project is discussed. People talking about the "power of Java" don't really know what they're talking about, or have never actually used it.

Re:Does it scale?

[ashot]

Python is one language they actually use quite a bit

Re:SQLObject rocks!

[ambilio]

Sounds like an Object-Relational Mapper. You can find these for just about any platform out there: Ruby - ActiveRecord, Java - Hibernate (and *many* more), PHP - Propel. Explicit SQL is also optional with these.

Small Wikis

[xihr]

If you're up for small Wikis, there's always HeyHeyWickie [python.net], a Python Wiki in under 4K lines of code (using EmPy and docutils).

Re:OpenDoc Cookbook

[Bogtha]

As far as web work I've slowly become disenchanted with PHP. It's a good language to be sure but it's simplicity is short-lived. As you want to do more complex things you end up having to work around PHP more than you get to benefit from it.

That's exactly what I found. I was already familiar with Python in non-web application domains, so I started looking around for decent web application platforms for Python. I settled on mod_python, but the templating was awful, and none of the alternatives seemed much better.

I'd actually gotten most of the way through implementing a PHP compiler for mod_python* before I discovered Kid, [lesscode.org] the templating system used in Turbogears. It really hits the sweet spot where it's not too rigid like other XML-based templates, but not too loose, unstructured (and just plain bizarre) as other Python-in-HTML systems.

I'd highly recommend trying out Python + Kid for any decent PHP coders, even if it's not specifically TurboGears (which I haven't tried out yet). After the first couple of days, your productivity will shoot up and you'll wonder how you ever managed to cope with PHP.

* Compiling to Python bytecode is simple, it's the irregularities of PHP that's the bitch. PHP is a fairly nice templating language, which is what it was originally - it's just the actual programming where it sucks.

Re:Rails everywhere.

[Anonymous Coward]

To me it seems like a silly exercise to replicate rails in python or what have you. Ruby is easy to pick up and a nice language to boot. Why bother really? Just learn ruby and get on board.

Because Ruby programmers are few and far between? Because your existing team already knows Python? Because, like it or not, functional programming has been trying to hit the mainstream for decades without result because functional programming is not as easy and straightforward as imperative programming. Because you already have a lot of Python code already written and working.

For a thousand other reasons. Tell anybody in the real world "oh, just switch languages!" and watch yourself get laughed out of the building. Ruby is far from being a panacea, and even if it was, there's plenty of good reasons to stick with what you already have.

Visual Programming

[youval]

My project, Tersus, uses an alternative approache to web application development. Take a look at http://www.tersus.org/ [tersus.org]

Well, they didn't get Slashdotted

[shis-ka-bob]

I was pleasantly surprised that the TurboGears site not only came up, it came up fast. Quite unusual for a new developer framework appearing for the frist time on Slashdot. Especically since 'Python', 'Ruby on Rails' and 'AJAX' were mentioned, I'll bet they got hammered pretty hard in the last few minutes. So at least we can see that the server scales pretty well with the number of users. This could mean nothing more than the site uses a cached home page and we are seeing the value of (something like) Squid. No matter what the cause, it is encouraging to see thay they didn't get swamped by all of us checking out the new tool.

Question

[g2devi]

> For anything substantial, though, it always seem to wind up
> being more work as I figure out how to configure & trick the
> persistance layer into giving me my data in the most efficient
> way. This can be frustrating when you know how to accomplish
> the same thing in 5 seconds using plain SQL. Maybe it's just me?

That raises a question about these persistence layers. Most of the tables we create use an "always insert, never update or delete" model so we can keep track of who made the change, when the change was made, and by whom.

You have to code, normalize, index, and select from these tables in a particular way otherwise you'd end up with extremely inefficient code. I just don't see how a persistance layer can handle this.

Another thing, one thing I've learned is that for enterprise applications, data outlives the application and in many cases, it predates the application. In essense, the persistence layer will need to be retrofitted into the application. Top-down GUIs like the ones presented for Rails appear to be of no use. We already know the exact representation of the data so Rails will need to work from the bottom up by default.

As a side note, I don't see why people are so afraid of a little SQL. Sure it takes time to learn how to master efficient SQL coding, but it's well worth it. It's the most efficient way to deal with most data, and because it's a declarative language, it's often more intuitive than the imperative language you're working in. It's also supported by most languages, so it's universal. If you're using a strict model-view-controller paradigm, database access will be restricted to the model and recast into data objects that can be used by the view and controller. If done correctly, you can rewrite the data code of several applications every day of the week without affecting the view and the controller (i.e. the bulk of your code). From what I've seen, that clarity of what exactly is happening and how complex things are mapped really helps with maintenance and optimization. From trying to maintain persistense layers, I'm left trying to figure out "what on earth is the persistense layer trying to do that is causing so much trouble".

I've got one major problem with Django

[jocknerd]

I was very interested in Django since I love Python. It looked simple enough and I was able to get through the tutorials and thought that Django was my holy grail. But then I tried to adapt it to an existing database system I had. And here is where the project failed for me.

The problem I have with Django is that it wants to hijack your database. Sure, they make it real nice to start from scratch. You write classes, run some scripts, and next thing you know, its created a database and all the necessary tables and indexes. But what if you've already got a database? Well, they provide a way to use your existing database too. But unfortunately, Django wants to add its own stuff to your database. I find this unacceptable. If Django needs a database for its internal administration stuff, fine. Create a separate database for that. But don't throw your tables inside a database that may already be in use for other projects.

Plus, what if I want this database used for multiple projects. I don't think Django makes that possible.

Re:Object/relational mapping

[mikkom]

In other words, I want a single layer of cleverness: My domain model. Object-orientation is all about encapsulating clever. Letting it sieve half ways through to the database is a terrible violation of those fine intentions. And I want no part of it.

This works fine if you only have one program accessing the database but is terrible if you have multiple clients for example. Even worse if you have real "enterprise" environment with legacy apps and such.

Re:if you refuse to use Ruby, I guess this is okay

[lcracker]

You're comparing apples to tacos here. The SQLObject example contains the definition of the table, so that it can be automatically created if it does not already exist, where the ActiveRecord example depends on the existence of the table in the database.

As for the page example, clearly you have no idea what you're talking about. It says:

1. Expose an "index" URL as this method with the "wiki20/templates/page.html" template
2. Look up the content of the page in the database
3. Use docutils to parse the content of the page as a reStructuredText document, and get the result as an HTML fragment.
4. Encode the HTML fragment as UTF-8
5. Return a dictionary containing the page name and the HTML fragment for usage by the template (or a direct JSON request)

I'm ready... but I can't get it working

[MrBlic]

I've been following python web development for a while, and currently have a few sites running with Zope + Zope Page Templates + ZSQL Objects + MySQL and they work great. The only problem is that I want a more lightweight faster server.

I am all ready to try TurboGears, but I have not been able to get mod_python + apache2 running on my mac mini. Does anyone know of a howto that will make my TurboGears web app start when the mac starts and mix TurboGears with static content? I really want to follow this example http://www.jamwt.com/mpcp.py [jamwt.com] but don't quite know how to get past some compilation errors with mod_python on my mac (OSX 10.3) and convert this to be TurboGears-aware instead of just cherrypy aware.

The Kid templates are a great alternative / improvement over the Zope Page templates. The pages are cleaner and I don't have to look up how to do tal:defines as often. I would probably not use SQLObject, but instead start with Durus.

I'm just waiting a few months for it to become even more of a no-brainer for me.

-Jim

Re:Rails everywhere.

[Ian Bicking]

I added this feature (using the database as the source of the model) to SQLObject a couple years ago, before I'd ever heard of Rails. But, after adding it, it never seemed like that neat of a feature, and it only gets moderate use. I don't claim SQLObject was the first... rather that it's not that great a feature compared to using the class itself as an authoritative representation (which no one uses in Rails because they don't have a choice, since ActiveRecord doesn't implement that).

No one familiar with Python development should have ever been wowed by anything Rails does from a technical point of view. All the surprise about these features is coming from Java and PHP people, who have lived in darkness and to whom all light is blinding and full of amazement. I don't have a problem with that -- you'll get no arguments from me that Rails is better than what PHP or Java offers. But it doesn't mean Rails is novel.