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.'"

no sql?

[ambilio]

...not a single SQL query in sight...

Why is this an advantage?

Video software

[The OPTiCIAN]

What software do people use for making these neat videos? (I realise this is bordering on off-topic :) )

Re:Does it scale?

[Anonymous Coward]

Amazon don't use J2EE most of it is written in C/C++.

I'm sure there's a Google engineer chuckling at the thought of using J2EE for their entire system. If anything Google are quite varied in what languages they use I expect, like any sensible company. If your too tied to a single language, your screwed in the long term.

Java != Panacea.

Peon.

Scaling up, and scaling down

[DavidNWelton]

Ok, so some of these tools are not suitable for running Amazon. But guess what - most people are not running Amazon! A lot of people don't have the development resources that amazon has, either, so what they are really looking for is a sweet spot that lets them get going quickly, and will grow within reason.

I'm still mulling it over and working on it, but I talk some about "scaling down" in this article:

http://dedasys.com/articles/scalable_systems.html [dedasys.com]

You're right of course that you don't want stuff that falls over the first time traffic spikes a bit, but you absolutely must have something that you can use to produce a functional product. You can have the fanciest, most scalable system out there, but if you spend two months twiddling with XML config files, things just aren't going to work out.

OpenDoc Cookbook

[Graymalkin]

I'm definitely not an expert in Python, in fact I've only ever given it a cursory look. However that tutorial was damn impressive. Obviously he had some prior knowlege of Python and using TurboGears but it is really not all that difficult to build something like a Wiki using that framework. 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. A large web project in PHP ends up structured like a project of similar size in Perl or Python. Between TurboGears on Python and Ruby on Rails it looks like I have some reading to do.

Re:Does it scale?

[Scarblac]

if you want to do something for your professional career, don't waste your time with those kind of frameworks.

If you want to do something for your professional career, get familiar with as varied a collection of tools as you can. Know the pros and cons of each. Actually test their performance, make toy projects, steal ideas and patterns. Be opinionated, but prepared to honestly choose the best tool for the job you're given, and to explain why it is the best, to suits and to techies. A few hours getting to know something new is never wasted.

10 seconds in [your language here]1

[Anonymous Coward]

new Weblog(); new Wiki(); tadaaah!

Rails everywhere.

[killjoe]

If imitation is the sincerest form of flattery then David Heinemeier Hansson must be blushing right now. His framework has insipired every other language proponent to make a rails like framework. There is trails in java, django in python (and now turbogears), there are at least two PHP frameworks and even a .NET one. I think somehow David touched a nerve someplace and produced something really beautiful.

Much of what makes rails great is the highly dynamic nature of Ruby itself. Do yourself a favor and read the activerecord source code. Even if you don't know ruby it's an interesting lesson on how to take advantage of dynamic scripting languages. I am sure python and PHP could also do something like this but the Java and .NET people are resorting to code generation to try and mimic some of the functionality of rails.

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.

Re:Rails everywhere.

[hexene]

Although only recently open-sourced, Django has powered real-world sites for several years now. So whilst the project will borrow ideas from other frameworks where it makes sense, it's more of a case of parallel evolution than trying to ape Rails.

Re:no sql?

[VGPowerlord]

Why is this an advantage?

It makes it easier for the programmer.

However, I really wrote this to say what it is not an advantage. I have two words for you: Outer Joins.

First of all, an Outer Join (of which LEFT JOIN is the most common) is used to get information from two tables, whether or not the information in one table has matching information in the other table. A real world example would be a list of customers and the number of orders they've placed with your business. With a normal (inner) join, customers who have never placed an order would not be listed.

I keep seeing people mentioned SQLObject, so I'll pull up a selected reference to the SQLObject FAQ [sqlobject.org]: "How can I do a LEFT JOIN? [sqlobject.org]."

The Simple method on that page is what I believe is referred to as the "1+N" problem. 1 Query becomes 1+N queries, where N is the number of results in the first query's result set. Needless to say, this doesn't scale well.

The Efficient method is actually much more complicated than the SQL to do the query, and it still takes 2 queries to boot.

This is why you'll never see a large business relying on an SQL builder to build queries. In the hands of someone who knows what they're doing, hand written queries are optimized much better than generated ones.

Re:Does it scale?

[Qbertino]

Wrong.
If you're building Amazon or a simular service (million visits/day) everything scales. I don't know the exact budget the Amazon portals had, but buying Guido von Rossum or Larry Wall and ten of their favorite programmers for life would've probalby been less than a month of amazons electricity bill.

If I were to rebuild Amazon I'd actually consider Python. If the VM doesn't cut it, I'd hire 20 programmers to optimize it. Which, btw, I don't think would be neccesary.

Another scenario is even more realistic. MySQL sucks for certain purposes. But if a certain OSS CMS I like only runs with it, but the project is big enough to imperatively require Postgres or Firebird, then the projects budget should allow to patch in support for that DB.

Re:SQLObject rocks!

[moro_666]

  stored procedures and triggers *are* code - its a hack to follow the "do it all in the database" mentality.

no kidding, they are indeed code, but this code mostly is on the other side of the database pipe/socket/stream/ which is very important. for example if you update 500 000 records then a database side trigger is affordable ... but any hack in sqlobject or is just awfully slow and inefficient.

dont get me wrong here, i like the sql to object and vica versa mappings, the idea is cool ... but it always comes with a performance penalty, and if your project planning isnt provisional enough, you might end up using the cute toy in the very wrong space and after all the hussle you just rewrite the code to some sort of optimized stuff. and using the sql-object layer with an additional hack to get the same speed is actually much worse in terms of portability than either one of the pure implementations (either pure object-sql bridge or pure sql code without any bridge at all), and the most likely one to break too.

choose the right thing for the right job.

and no, i dont think we need another wiki ... maybe it's time to evolve to a next level and invent something totally new ?

Ruby functional? Not.

[archeopterix]

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.

Ruby is no more functional than Python, even by the most twisted definition of 'functional'. Yup, it uses closures (aka blocks) and that is how far it goes towards functional. For a language to be functional it is essential to restrict side effects (haskell with monads, ocaml with 'mutable'), or at least have some good support for no-side-effects programming: currying, higher-order functions, the "let x = expr1 in expr2" (aka non-destructive assignment) construct and so on. Both Python and Ruby make routine use of destructive assignment, which is the epithome of side effects.

Proof is Slashdot itself

[arevos]

Slashdot itself uses Apache/mod_perl/MySQL, and there's little between mod_perl and mod_python in terms of performance. Slashdot handles 3 million pages per day without any trouble. Does Slashdot not count as a 'large site'?

The idea that J2EE is the only system that can handle high traffic sites is a myth.

Re:Ruby functional? Not.

[csirac]

Ruby is far from perfect and declaring that we should drop all development in other languages and immediately switch to it is just plain fucking stupid and lacking in any pragmatism whatsoever.

Perhaps he's not saying Ruby should become a new standard, but that people like you should open your mind just a little, tiny bit, open the door and walk outside - and try a new language for a few hours sometime.

People like you like to get stuck in a rut and cling to what you know, forsaking everything else. For years, all I've ever known is C, 8/16-bit ASM, Perl, a few FPGA HDLs... even if I don't do websites or databases, RoR has inspired me to climb out of my comfort zone and take on something new. Guess what? I've discovered a language which looks to be a new favourite of mine. I'm going to use it now instead of where I would have used Perl.

You can't even distinguish it from Haskell and functional programming, but yet you seem to think you're qualified to say how "perfect" it isn't... no wonder you're posting AC.

Re:Does it scale?

[m50d]

Google uses python all the time.

Yeah, why use SQL halfway?

[TheLink]

Yeah, that's the part that gets me wondering. People keep talking about hiding away the SQL. But if they don't want SQL, then why are they using an SQL RDBMS in the first place?

Shouldn't they be using something else then? Otherwise they'll get the drawbacks of using an SQL database but fewer of the advantages. What happens if performance in a particular area is not good enough?

Say you want to store a session in a database and you want it to expire after X seconds of inactivity.

A simplistic method would be to update the session row each time there's activity. But this would cause lots of writes which would be slower in most proper databases (those that actually write to disk for writes). An alternative would be the databases equivalent of "update sessiontable set lastactive=now() where sessionid='$sessionid' and lastactive+'1 second' <= now()".

With this, you could have thousands of hits per second but only 1 forced write to disk per second due to that query.

How would you achieve this when you're so abstracted away from the SQL database? And it might look strange to others when you try to do the same thing N layers above the database. I'm sure there are better examples.

Those sort of queries are likely to look different on different RDBMSes. You could make a function that looks the same, but someone still is going to have to write the SQL for portability (and sometimes bad luck, it's not possible - DB doesn't support functions or that sort of function). Also, if only the program's session module does that stuff, then what's so bad about leaving the SQL in there? At least then there'll be some context to understand the SQL (and whether it's wrong or right ;) ), rather than it being neatly stored with 1000 other nonrelated SQL statements (as functions or otherwise).

Sure it's ugly. But if people want it all so elegant and clean maybe they should write _everything_ in some version of Lisp, and not interface with the rest of the ugly real world.

Re:SQLObject rocks!

[njyoder]

if it's mixing in dynamic SQL queries there's a good chance it also has SQL injection holes.

I'll take that "if" to mean you haven't read the documentation and didn't actually watch the video. Stop frothing at the mouth about SQL injection holes. If you had bothered to watch the fucking video (which you didn't), you'd notice it has specific mechanisms to deal with them.

Also, its main purpose isn't to "catch bugs", it's to make things easier on the programmer. Abstraction toolkits like this are good. God forbid someone make things easier.

I call BS. First off, SQL is a set-based language. Very rarely do you need to loop over a result set (if you find yourself looping in SQL code, you're not thinking hard enough). Whatever "loop and operate" action you'd take with Python can be done quicker and more efficiently with SQL code than with app code.

And I call BS on your BS, because you didn't actually read what you were responding to. I'm beginning to notice a pattern here, first you start frothing at the mouth based on speculation from not having RTFV (video), then you do it for not reading the comment you're responding to. They specifically used the descriptive words "powerful" and "easier" not "faster." The issue isn't effeciency, no one is claiming that TurboGears produces the most effecient code. The whole purpose of TurboGears is to make things easier on the programmer, which is what this does. Designing the logic within python, which actually does allow you to do quite a bit more in terms of 'business logic', makes things easier.

Finally, while it may be "easier" for a developer proficient in Python and not the SQL dialect used by your chosen DBMS, that's a cop-out. As so many people are so fond of saying, you should use the right tool for the job

No, even for someone very proficient in SQL it's still easier in Python due to these bindings. Of course, not having actually read anything about TurboGears (e.g. the documentation) and engaging and rampant speculation and all, you wouldn't know that.

And they ARE using the right tool for the right job, you should follow your own damn advice. TurboGears is designed for jobs where EASE is a priority over effeciency. GUESS WHAT, effeciency isn't always the #1 priority, genius.

You speak boldly, but you can't read worth shit, excercise critical thinking skills nor even follow your own advice.

I've intentionally ignored the problem of database portability, because a) you should be using stored procedures, which means you'll want to port them yourself anyway for maximum benefit, b) you should be using a proper DBI layer such that you just have to tell it, "I'm using Oracle now instead of Postgres, do the right thing", and c) because you're using stored procedures, you won't be switching to a DBMS that doesn't support the

A isn't even a "reason", it's just a circular statement. "You'll want to do it because you'll want to."
B isn't valid either, which leads me to believe that you're not actually a database programmer, since DBI layers don't just magically translate from one proprietarism to another. If you DO use an sql stored procedure, you're forced to stick to strict standards, otherwise the DBI layer becomes useless.
C is just a lame excuse to bash MySQL, it's not even a real reason. Keep on frothing there, buddy.

Using a bulldozer to kill weeds

[porkThreeWays]

J2EE based web services are 900 pound gorillas. Sure, amazon etc use it, but I don't spend my day making amazon.com's. I spend it getting requests from various departments for single purpose programs that are web based (so we don't have to maintain yet another fat client on the desktop). These simplier frameworks make it possible to make quality web applications quickly. Most of these programs are just a varation on a theme. 2 or 3 tables with maybe a foreign key and 3 or 4 web pages. These frameworks make it possible for me to give them a finished application in a couple of hours so I can spend my time doing more important stuff.

A necessary evil

[Kaseijin]

But if they don't want SQL, then why are they using an SQL RDBMS in the first place?

It's a robust data store that isn't tied to any one application language or object model. Often, SQL per se isn't the problem, but differing dialects are.

How would you achieve this when you're so abstracted away from the SQL database?

Use a mapper with the required feature or drop down a level. Abstraction isn't all-or-nothing.

Those sort of queries are likely to look different on different RDBMSes. You could make a function that looks the same, but someone still is going to have to write the SQL for portability....

If someone already has, why should I do it again?

Re:no sql?

[holle2]

It shows a high level of abstraction when you access the DB by simply loading/persisting objects [...]

Last time we used an object-to-sql mapper was quite some time ago, so my info might be outdated:

We attempted to create objects (in Python) to store a lot of attributes ( > 30 ). The design explicitly asked for a "flat" database.
All this happened inside Zope [zope.org]/Plone [plone.org], so we tried out the Archetypes [plone.org], which come with a hand attributes (or better PropertySheet) to SQL mapper. But the code was that ugly, it created a single SQL insert/update statement for each property (attribute) even if it did not change.
This resulted in an extremely long running "save" operation that you could simply throw the code out of the project ... . The data is now stored in the Zopes own ZODB and gets archived after a while in a SQL DB.
For archiving purposes a hand-crafted SQL statement is used that runs lightning fast :-) .

On the other hand, I have seen Java code querying an SQL DB using the Oracles TopLink product to abstract the underlying database. The code was so gross, you simply felt the urge to go and wash yourself after looking at it.

The result of this experience is:

• If you want to concentrate on your object oriented approach, stick to databases that can handle objects, like the ZODB [zope.org] (usable w/o Zope if you like).
• If you have to access mass-data from legacy systems (like e.g. master product data), you have to program SQL, since nothing is faster than that. Make sure the results can be converted into something like a list of dictionaries so handling of the results is more natural in an object oriented manner.
• Every good programmer should be able to switch between programming languages and be able to access data stored in legacy systems as well. Sometimes the data comes only via an ODBC connector from an old AS/400, but if that is the source of the master data, you have to live with it.
• SQL databases are not the primary choice to store objects and/or tree like structures. They were designed it the "good ole' times" when everybody though that relational databases were cool. Sometimes it can be much more useful to store a tree in an object persistent storage and put the node data into an SQL DB (for performance).
• For debugging: If you use SQL code in your project you can actually print out the statements before they get send over to the database so you can simply copy them from your logfile (you have a logfile, do you ?) and run them manually to see if they produce the outcome you want. This is often more useful than enabling query logging on the server since digging through thousands of lines of log-messages can be rather time consuming.
• For designing: You can build your queries step by step in a "Query Analyzer" using some example data and then embed the results into your code (including the exchange of fixed teststring with variable names).
• For performance: You might know that you have to run a query 3000 times in a row with different variables (e.g. insert into ...) but you object mapper does not know that fact. Thus you can use one prepared SQL statement and fill in the variables upon execution. This saves a hell lot of time (depending on your database system, some systems are slow either way).

Ok, I got my flame shield up, let 'em come ...

Re:You're not getting "functional programming" rig

[Anonymous Coward]

This is not so with Python, whose design is in fact evolving to discourage a functional programming style (Guido has repeatedly rejected adding anonymous closures to the language, and is planning to get rid of built-in functional combinators like map and reduce).

Point the first: nothing that you mentioned has yet been removed from python.

Point the second: map and reduce are on the suggested drop list in favor of other functional programming constructs like list comprehensions and generators that do the exact same thing with cleaner syntax. Because that's what python is about ... reduction and simplicity without losing functionality.

Point the third: please explain how anonymous closures are superior to lambda constructs, list comprehensions, or generators each used in the appropriate context.

Re:You're not getting "functional programming" rig

[arevos]

Here I'd respond that Ruby provides much more natural support for higher-order functions (because of blocks), its libraries are designed around them. It's actualy hard to avoid using them any time you program in Ruby.

I think you'll find there's not too much difference between Python and Ruby in this respect. In Ruby, code such as this:

method(method_args) { |yield_args| code }

is just about equivalent to this in Python:

for yield_args in method(method_args): code

Ruby and Python take different approaches to the same problem, but I'd hesitate in saying one was clearly superior to another.

This is not so with Python, whose design is in fact evolving to discourage a functional programming style (Guido has repeatedly rejected adding anonymous closures to the language, and is planning to get rid of built-in functional combinators like map and reduce).

That's because list comprehensions, generators, and inner functions do the same thing in a more Pythonic way. No functionality will be lost with the disappearance of lambda, map, filter, etc.