25 Jan 2005 titus   » (Journeyer)

Hey, salmoni, major congrats! I hope to defend RSN, myself...

Rails:Ruby :: Zope:Python

(just five years later ;)

I love hype; back when, I remember seeing people post "I want to write a Web page in Python, what do I use?" and getting "Zope is the answer!" as the response. Given Zope's size, complexity, and overwhelming amount of functionality, I didn't think this was the right direction to point Python newbies. It all seems to have worked out in the end, though: there's now a diverse and healthy population of Web frameworks available for Python, and you can choose what you want. It may be more confusing for newbies than the old "use Zope" advice, but the flip side is that there are now several good options and some healthy competition in the Python Web space, you can have it your way.

Now Ruby on Rails shows up & people freak out, with the Ruby people claiming that "this can't be done in Python" and the Python people saying a variety of polite and impolite things in response. ...and then there are the users complaining about lack of documentation, which was my beef with Zope back in the Dark Ages.

I have yet to see any evidence that Python and Ruby are substantively different, but I haven't looked much beyond c2.com. I tend to like Ian's take on things, and he thinks it's less a language thing than an app/integration thing. It sounds like rewinding the clock by 5 or 10 years and building a leaner, meaner Zope with Python 2.2 would result in the similar advantages for Python: One True App Framework. (It is an interesting (if odd) take on things to say that we would be better off with less choice! Smacks of B&D to me.)

Instead, we're stuck with a multitude of Web/app frameworks in Python, which people seem to think is a problem. Hey, folks, maybe (as with GUIs) there's more than One Right Way to do this? Just a thought...

It is clear that some people just can't take a joke ;).

PostgreSQL 8.0 & ORMs

PostgreSQL 8.0 now supports savepoints. Back when, I argued that any standard persistence framework for Python shouldn't require functionality not available in at least open good open-source SQL database; my main complaint here was that savepoints somehow became an issue in the Persistence-SIG discussions.

It may be time to dust off cucumber, which was developed before Python 2.2, and update it. cucumber is my ORM linking Python to PostgreSQL with class inheritance based on PostgreSQL's table inheritance. I've been using it for 3 years, and one or two other people discovered it & used it for a bit. The only two complaints I've received are that it's slow (well, OK, yeah...) and that it defeats introspection. I think the former is insoluble and the latter could probably be remedied with metaclasses, although I'm not sure.

I'm still quite happy with cucumber, and it's saved me hundreds of hours of programming. I'm still wedded to the idea of having an SQL interface for my data, and when you add in the great feature of table inheritance (which seriously reduces ORM impedance mismatch at the expense of tying you to PostgreSQL) I don't think the idea can be beat. (My code is another matter...)

...or I could just switch to using SQLObject, which is becoming a frequently observed keyword in Python fora.

--titus

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!