First of all, for those tuning in, the title is just a joke. I'd like to believe we're having a reasonable discussion. Leon has replied with some interesting observations and questions which I think need answers.
I think I sound more dismissive of Rails than I am. It's not that I don't think it's a great idea and direction - it's more a response to, as Leon says, the hype. Rails has one big advantage - it's galvanising the web-application-building Ruby community behind it.
Which is where one should bring up WSGI. WSGI is simply a way to write a Python web applications that will run on the various available application servers (or via CGI, or whatever). WSGI's potential is that it will galvanise the Python (and excluding Zope for the moment) web-application-building community to a single way to write an application. Which isn't all that useful of itself, until you figure in that this allows anyone to write libraries that rely only on WSGI-available information, which can then build an integrated environment much like Rails.
Subway is a potential Rails-competitor, but it uses CherryPy. That may change now that WSGI is solidifying and implementations are available.
Back to Leon's other comments. I think he's got something in terms of SQLObject's column descriptors (when not reading the schema from the database) being useful for versioning. I also think it's useful in terms of database portability - which isn't usually useful for developed-for-self applications, but may make Open Source projects find more potential homes.
MVC? Done how? I truly like the way the code looks in Zope (X)3's object publishing via view adapters. I typically end up doing MVC, with very close interaction between the View and the Controller. Either the View interrogates the Controller for how to build itself or the Controller sends lots of stuff to the View, and that usually means the Controller is controlling the way the View is displaying content too much. Which makes me feel like I've missed something obvious.
I agree with regards to Views being regarded as bastard third-cousins. Except, I like the Cheetah template language more than if I had pure Python available, I think. But in Cheetah's case, one can think of it more like an alternative syntax for the same language unlike, say, Smarty or TAL (or, if you're really unlucky, DTML).
What about them?
Eh. I've read the WSGI spec and of all the specs I've read, it's one of 'em. You mention Subway and then say "but ... CherryPy" as though it's a cautionary note, as if by virtue of WSGI's existence everyone should simply kneel and fold their hands in prayer. I'm not at all convinced. Exactly which benefits does WSGI provide to me, an app programmer? I've just written a thousand lines of Webkit: how is WSGI going to make me happier? It seems to me the benefits are primarily for library and framework programmers, not app programmers, and since I spend about 80% of my day doing app programming, well, I'm looking for anything that makes my life easier and less stressful to live. I love CherryPy because it does both of those things effectively. Until I see how WSGI does this for me -- a please pardon me if I'm suffering from a huge lack of vision here -- I'm neutral on it. Also, before anyone lambasts me for being blind to the benefits of WSGI, please be careful to make distinctions -- as with Rails, or Struts, or Eclipse, or what have you -- between concrete examples and ecstatic proselytizing.
I wasn't saying "but it uses CherryPy" in a cautionary way. In the previous paragraph, I was talking about WSGI's potential to galvanise the community and allow cross-application-server libraries and frameworks to emerge. I then recognise Subway endeavours to be a Rails competitor, but that it doesn't fit into what I was talking about before w.r.t. WSGI. As to why to use WSGI? Now? No real point if you want to build once-off applications. If you're wanting to build a cross-application-server application or library, then it's a good place to look. It seems to have potential - not for its specification, but as a base platform on which the divergent efforts that currently happen on one application serving environment can instead be built. That said, I'm building on Webware now because I want to get this project finished sometime soon (considering I have to fight my procrastination).
I think the most critical thing to understand about Rails is not the galvanization of the community, but what has lead to that galvanization. Most directly it's that less code is better. In every framework to date to get less code you've had to give up functionality. Ruby makes it possible to have both -- presuming you have a powerful framework design. Rails embodies that design. The combination is devastatingly powerful, hence the community piles on. Once that happens the framework continues to get even better. Had this happened anywhere else (Java, PHP, Perl, Python, or even a different Ruby project) we would have seen the same thing. The crucial thing to realize (which is apparent in the long movie David has on the rubyonrails site) is that Ruby was critical to building this framework. Perhaps we can have a real Python on Rails someday, which would be a good thing -- less code and more power being the goals here. It's telling to me, however, that not only was Rails not first written in Python (or any other language but Ruby) but, even with the Rails source code in public view, the discussions seem to indicate that noone knows whether Rails is really even possible on any other language. I think this has a lot to do with why the people who "get" Rails get it instantly, and those who don't can't see what the big deal is. Best, Rick
Don't forget to have a look at another Ruby Web Framework called Nitro (http://www.nitrohq.com). Nitro integrates the powerfull Og ORM library, provides most of Rails features and then some ;-)