Slashdot Mirror
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.'"
I've used Python/SQLObject/CherryPy on a project before. It's very quick to code something useful. SQLObject will change the way you think about how you integrate DBs to web applications. All in all, it's well worth checking out.
It shows a high level of abstraction when you access the DB by simply loading/persisting objects instead of having to handle queries, result sets, records and all the other low-level stuff. And abstraction (in this case) is good, as it helps the developer concentrate on the relevant parts of the program.
A monkey is doing the real work for me.
One of the nicest features of SQLObject is that it insulates you from the peculiararities of the database's SQL syntax, so you don't need to put any SQL code directly into the Python code (but you can if you need to for efficiency or if you're willing to write non-portable code).
The SQL database abstraction layer is an important feature of SQLObject, that Ruby on Rails doesn't currently support -- you have to write database dependent SQL code mixed in with your Ruby code.
SQLObject lets you write generic SQL queries with normal Pythonic expressions and operators, which are automatically translated into the database dependent SQL syntax by the database driver. So you don't have to change any of your Python code to port it to a different database, and you don't have to mix together two different notations, or quote a bunch of SQL strings in your Python code. It's a much more "pythonic" way of database programming than raw SQL.
The great thing is that it's so convenient and the syntax is so simple, that you can use the interactive Python shell to browse and test out and edit your database. It's trivial enough to type in some Python code on the keyboard that loops over the results of a query, performs some complex logic, and validates and edits a bunch of rows in the database. Much more powerful and easier to use than anything you can do with raw SQL.
-Don
Take a look and feel free: http://www.PieMenu.com
Since it was made on a mac, my guess is Snapz Pro X.
http://www.ambrosiasw.com/utilities/snapzprox/
My other car is first.
torrent
What software do people use for making these neat videos?
vnc2swf
And to bring us (nearly) back on topic, the latest version is written in python!
The world has changed and we all have become metal men.
Other people have answered in-depth, but the short answer is:
a) You do not need to worry about which vendor's dialect of SQL syntax you're using - provided you know how to create and populate the tables in any database system, you can switch at the drop of a hat if you need or want to.
b) Provided the layers are stable, it protects you from SQL query injections. The abstraction layer does the escaping for you.
c) Abstracted queries makes queries 'just another function/method call', and you get ordinary data structures back. This in combination with a) and b) and a competent framework (Rails, Django, TurboGears, Cake, Trax, WebObjects) makes coding much quicker as you don't have to keep the semantics of SQL and your database in mind - just the model itself.
There are *many* nuances to this, but the above three are some of the most pertinent ones. Peruse the other comments if you want to get in-depth.
Tried TurboGears, but the fact that it's a glue was way too appparent. I then moved on to trying Django and fell in love. All the stuff TurboGears can do Django can too, but natively.
Persistance layers are cool for a lot of reasons. Though, it definitely takes some getting used to for those of us who have developed a lot of SQL driven applications.
Don't let anyone fool you into thinking that a persistance layer will be less development work for you - I have found this to be untrue. I can use automated tools to get myself 80% of the way there. 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?
But, if you do manage to get over the hump, the benefit is that your business logic layer is very clean with no DB code whatsoever. If you use it properly, you can get 100% separation between these layers.
If you're using a strongly typed language, you get the added bonus of compile-time checks for certain illegal assigment errors. You don't have to fumble around with things like converting dates into SQL. You don't have to check for SQL injection. Lots of other little things.
TODO: come up with a clever sig
Also worth checking out: Twisted. I haven't had occasion to use it myself, but people I know swear by it.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Whilst Rails is an excellent framework for web applications, I've found that it gets exponentially more difficult to work with when your database structures grow more complex than interconnected lists. I recently designed a double-booked accounts program in Rails, and whilst most of the code was simple to design, I quickly got bogged down in handling the accounts-tree and the double-booking of financial records. Here the documentation ran out, and I was forced to go through the Rails source to discover a solution to my problem, which turned out to be less than optimum.
Secondly, whilst I have done a fair bit of work in Ruby, I can't help but prefer Python. If there's little difference between Rails and, say, Turbogears, Django or Subway, then surely it comes down to personal preference. Python web frameworks appear to take a more piecemeal approach than Rail, which can provide a more flexible solution in certain situations.
Can't say I much like SQLObject's syntax, though; but CherryPy seems rather elegant.
Have you even looked at Ruby? It is not a functional language by any stretch -- it is very similar to Python and Perl. It is by far the cleanest one of the three built with objects from the ground up.
If there is something you need to specifically query by hand in SQL you just use find_by_sql in Rails. I'm not sure how this is configuring and tricking it?
yeah, Maypole and Catalyst.
"...we should just trust our president in every decision that he makes and we should just support that." B.Spears 2003
Rails has taught us some important lessons, but they aren't really technical lessons:
After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.
As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.
Well, no points for the docs on this one (hey, it's open source) but there is some help for outer joins noted here.
Python has ONE (ok, one and a half if you count Jython) implementation
I'm not disputing your basic point, but there are many Python implementations. Off the top of my head:
CPython (aka "standard" Python)
Jython
Stackless Python
IronPython
PyPy
CPython, Stackless, and Jython are real production implementations.
PyPy is rapidly headed that way (and already self-hosting and passes more than 95% of the Python compliance tests). One of the primary developers is Armin Rigo, who did psyco (the specializing dynamic Python compiler that achieved speedups of up to a factor of 100 for numeric code).
IronPython looks to be abandoned.
rage, rage against the dying of the light
You're saying that a statement that does *less* than the other one is easier to understand. Way to go, Sherlock.
Now let's try a comparison between statements that do the *same* thing. First, the one using the block to manage resource allocation and deallocation:
Net::HTTP.start( 'www.ruby-lang.org', 80 ) do |http|
print( http.get( '/en/LICENSE.txt' ).body )
end
...and second, the *real* equivalent without blocks:
begin
http = Net::HTTP.start( 'www.ruby-lang.org', 80 )
print( http.get( '/en/LICENSE.txt' ).body )
ensure
http.close
end
Needless to say, the block version is shorter.
Anyway, this pattern you see here is one of the most common Ruby idioms, which you should get the hang of if you're learning the language: using blocks to decouple code that manages a resource *through its whole lifecycle* from code that use the resource. It's always like this:
Resource.acquire {|resource|
# do stuff that requires resource
}
# resource has been released, without you having to say so,
# even if the there was an exception
The same pattern applies to files, network connections, database result sets, thread locks, anything. Sure, it's unfamiliar to *you*, but you only need to learn the pattern *once*, and you reuse it all the time for different kinds of resources.
And to top it off, you can write your own methods like acquire() above in Ruby itself, just by using yield. This is not some special syntax sugar for resource management--this is just blocks. Here's the pattern for writing a method like acquire():
def acquire
begin
resource = low_level_acquire()
yield resource
ensure
resource.low_level_release()
end
end
Are you adequate?