TurboGears? Hmmm. Try Django.

I'm going for 2.0.

Following the instructions here:

sudo easy_install -i http://www.turbogears.org/2.0/downloads/current/index tg.devtools

Naturally, I got complaints, so I had to do this:
easy_install -U setuptools

Nope. It seems that no force on earth can update the default MacOS install of setuptools, so I just deleted it. The newer one had been put into /usr/local/bin by previous attempts to update setuptools (which is what the error message told me to do.)

We're still gonna need db drivers, so
sudo easy_install MySQL_python

The driver for sqlite is allegedly already part of Python.

So back to the install of TurboGears. The 2.0 docs are full of talk of "virtual environments" which makes me queasy. The reason I'm doing Python is simplicity, and that shit is not simple.

Like RoR (and PHP's ZF as I discovered) there is a CLI tool that sets things up. It's called paster.

So we follow the directions here: http://turbogears.org/2.0/docs/main/QuickStart.html — very well written, btw.

paster quickstart
blah blah blah

This is hell! It's worse than the PHP stuff! I wanted to go Python for simplicity, but this is a Heavy Weight Framework. Sheesh. Oh, it looks like a nice enough framework, but I am not looking for a PhD in frameworks. I just wanna get my app out the door! And, most important, I need something that is ISP-friendly. I simply cannot imagine doing all these arcane gymnastics in a user directory without root access.

Along the way I did
sudo port install python_select

and I love it!

So a quick
sudo python_select python26
and off to install django:
sudo port install py26-django

Front end to FMP

I need to build a Q&D front end for a FileMaker database. While the Server version of FileMaker ships with some PHP glue, I decided to go with a more familiar environment. Python! It's a nice language. I have some familiarity with it, and (most important of all) it works on the ISP's server.

I did a quick survey of some lightweight Python frameworks, and settled on TurboGears (with CherryPy) for the app itself. For the interface to FileMaker, I found PyFileMaker.

Ready to go! So, to begin with, I did a little spiking to kick the tires of PyFileMaker. Right out the gate, the results were disappointing. The code choked on my password! (Some regex seemed to believe that my password shouldn't contain special characters.) Not a problem: I created a special account for PyFileMaker (not a bad idea anyway for production) and got one teensy step further. I hit our FMP Server and asked for a list of databases. Kapow! Now PyFileMaker complained that one of the db names "contain unsupported characters." Pity it doesn't deign to tell me which one...

Well!

Foreseeing a life of misery and pain, I looked for a Ruby solution. A quick trip to the ISP... Whew! Ruby works there too. Anyway, it's high time I learned Ruby, so next stop, Rfm The visit to the six.fried.rice site was a breath of fresh air. I know from previous googling journeys that they seem to know what they're talking about. Best of all, they have a RoR sample app that talks to a FMP db, so I can start with that.

Into the world of Ruby!

Python plus OSA, vs. AppleScript

I have mentioned a few times that I have been using Python to talk in an AppleScript-like manner to Mac apps, via the appscript module. It is really exceedingly cool. It provides very tight control over when one does the “get” (i.e. the AppleEvent that actually hits up the app for some data) allowing one to manipulate references instead. This has the great benefit of a dramatic performance improvement over the brute-force approach one might use with AppleScript.

Correspondingly, of course, there is the fact that I have learned a great deal about how AppleScript works, and, should it be necessary, I'll be able to write much cleaner and more efficient AppleScript.

“More efficient?”

Well, yes.

And no, I am not violating the “don't optimize prematurely” maxim of XP, because AppleScript is universally, painfully slow. I pretty much know that anything I do in AppleScript is going to take forever at run time, so any optimizing rubrics I come across of are worth remembering.

And while we're talking about OSA... I have not had much occasion to use JavaScript OSA. I bet it's as nice to deal with as Python from the perspective of scripting scriptable apps. Of course, JavaScript is implemented as a “component,” meaning that it must be executed in an OSA-aware script editor (or via the osascript command) but there is no interactive interpreter available as there is for Python. Not exactly convenient.

The main reason I wanted to use Python (other than the fact that it's a nifty language and I know it quite well) was that I wanted to interact with a MySQL db. Easy in Python. From a purely OSA language like AppleScript or the JavaScript component, I'd have to have a scriptable app act as go-between. How would I do that? And can you imaging how slow that'd be?!

One more thing to try, however, might be to use the old MRJ technology to make a scriptable Java app. Then the Java app can use Hibernate to get at the db. Since the goal of this whole exercise is to integrate with a Java web app with Hibernate backend, the code reuse is obvious, and having to maintain two persistent layers is no longer an issue.

Pythonic IDE for Panther

Found it! No, it wasn't installed; it's available from the MacPython site.

Back to Apple's Python

My main objection to Apple's Python distro was that readline does not work correctly in the interactive interpreter. So I started using the Fink version. All was well, until I ran into the very frustrating situation I discussed yesterday regarding the inability to execute AppleScript from a Java app.

I thought I'd use Python instead. Rather than jump through all the requisite hoops to get the Fink Python to talk to Cocoa, I decided to revert to Apple's distribution, which does all that out of the box. All I needed was appscript to make AppleScript execution from Python completely painless, and off we go!

I seem to remember that there is an IDE of some sort that is part of the MacPython distro, which is pretty much what Apple has provided. Perhaps that IDE is hidden somewhere... I'll have to dig.

Then, of course, I vaguely recall that Eclipse can do Python.

Anyway, despite the annoying lack of readline support, I am back to Apple's Python, and happily executing AppleScripts. Onwards, upwards.

Web Scraping in Python

As I mentioned previously, I have been using the ClientCookie module for managing client-side cookies. The same person(s) produced a module called mechanize which provides a browser-like class that can be used to do some serious scraping, or to automate things like posting to web sites - perhaps even ones that require several steps of navigation before and after. [My solution also picks up the verification email containing the "confirm" url and does what's needed.]

The problem is that the web sucks. Well, HTML authors do at any rate. The particular site to which I am trying to automate access has singularly badly-formed HTML all over it. The cgi's it uses also generate bad HTML. Real browsers seem to take this in stride. But mechanize uses one of two built-in Python HTML parsers which are way too strict for the real world. They are easily confused by crappy HTML.

I have seen this problem solved once, in the Java world, by a framework called (naturally enough) HTML Parser. It's resilient and seems to manage bad HTML with ease.

So who's going to port it to Python?

Pythonic Ramblings - Redux

Of course, I could simply type setup.py -n install and it'll tell me where it intends to install, without the install. Live and learn - but that's what this blog is for.

Pythonic Ramblings

After hacking together some Python code that manages cookies from a client-side perspective (no urllib does not manage client-side cookies. Its cookie management is all from the server’s perspective.) I came across the ClientCookie module. I am in the process of trying it out, but since I already have code that works, this is an academic exercise. The simplest thing that could possibly work is in place, and I have no stories to drive a refactoring, and the existing code doesn’t smell. So.

Since I need to install a new Python module, I’ll use the usual setup.py dance. Hmmm. But wait; my python is the fink version (mostly because the Apple version does not use readline correctly, so you have no command history in the interpreter - really, really inconvenient. (I suspect their may be a licensing restriction on readline which prevents Apple from linking it into their Python distro. Whatever.))

So oh, yeah. setup.py, fink. Do I need to sepcify --prefix or --exec-prefix or both or what? Well, the following little trip to the interpreter gives me a hint:

>>> import sys
>>> sys.prefix
'/sw'
>>> sys.exec_prefix
'/sw'

So we’re probably OK. If not, I’ll post my findings.