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.'"
How do the python crowd expect to get taken seriously when implementing a wiki takes an whopping 125% as long in python as in ruby!!!!!!????
;-)
(oh wait, they did ajax as well..
Official GOD FAQ.
Why is this an advantage?
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.
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).
----
What software do people use for making these neat videos? (I realise this is bordering on off-topic :) )
Believe with me, my saplings.
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
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.
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.
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
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.
http://www.welton.it/davidw/
torrent
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.
I'm a loner Dottie, a Rebel.
As opposed to...?
As opposed to using transparent persisting of objects, e.g. with ZODB (which doesn't use SQL at all) or other persistance frameworks (which translate everything to SQL behind the scenes).
cpghost at Cordula's Web.
Python is one language they actually use quite a bit
-ashot
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.
I believe posters are recognized by their sig. So I made one.
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.
If you're up for small Wikis, there's always HeyHeyWickie, a Python Wiki in under 4K lines of code (using EmPy and docutils).
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.
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.
We suffer more in our imagination than in reality. - Seneca
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.
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.
Google uses python all the time.
I am trolling
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?
;) ), rather than it being neatly stored with 1000 other nonrelated SQL statements (as functions or otherwise).
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
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.
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.
If an officer ever threatens to taze you, say you have a pacemaker.
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
My project, Tersus, uses an alternative approache to web application development. Take a look at http://www.tersus.org/
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.
Think global, act loco
Rails is another example of innovation in the open source community, and will be conveninetly forgotten by the people who say there's no innovation in the open source community.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
> 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 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.
My quality social news site.com.
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.
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'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 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
Celebrate Excellence!
A few hours getting to know something new is never wasted.
I once spent a couple of hours looking at VBScript.
I think I came away knowing less about good programming than before, *and* I was out two hours.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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?
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.
I think you'll find there's not too much difference between Python and Ruby in this respect. In Ruby, code such as this:
is just about equivalent to this in Python:
Ruby and Python take different approaches to the same problem, but I'd hesitate in saying one was clearly superior to another.
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.