Looking forward to scripting
March 8, 2012 at 9:45 PM by Dr. Drang
I didn’t mean to ruin Clark’s evening with this tweet. I thought he knew that Hamish Sanderson had stopped developing appscript and was telling people to stop using it on new projects.
@macdrifter Um, doesn’t Devon know that appscript has been end-of-lifed? appscript.sourceforge.net/status.html
— Dr. Drang (@drdrang) Wed Mar 7 2012
(The tweet, by the way, was a reaction a link by Gabe [@macdrifter] to this entry in DEVONtechnologies’ blog. They apparently hadn’t heard about appscript being abandoned, either.)
Appscript was—and still is—a library for writing scripts that use Apple Events without having to write in AppleScript. There were actually three versions of the appscript library, one each for Python, Ruby, and Objective C. Clark and I were both users of the Python flavor.1
Appscript still works, and will almost certainly continue to work under Lion. But the Carbon API it depends on has been deprecated by Apple since Snow Leopard, so there’s no guarantee it’ll keep working beyond Lion. Sanderson was hoping that the replacement Cocoa APIs would gain the capabilities he needs to keep appscript working, but he’s now given up that hope. It’s a shame.
For me, the great advantage of using appscript was that I didn’t have to abandon the pleasant syntax and powerful text manipulation features of Python just to send a few Apple Events. I still struggled sometimes with the appscript syntax, but most of that was due to the underlying AppleScript syntax of the application I was trying to communicate with. My first use of appscript was back in 2007, and I was still using it in November of last year. By January, though, I’d learned that Sanderson was telling users to avoid it for new projects, and I did.
So what now? AppleScript is no substitute for Python, but without appscript Python is no substitute for AppleScript, either. I’ll have to render unto Caesar and use both. Most likely, I’ll write and debug the AppleScript parts in the AppleScript Editor, paste them into my Python scripts as multiline strings, and execute them from within Python via subprocess calls to the osascript command.
A simple example would be something like this:
python:
#!/usr/bin/python
from subprocess import *
ascript = '''tell application "Safari"
get URL of front document
end tell'''
frontURL = Popen(['osascript', '-'], stdin=PIPE, stdout=PIPE).communicate(input=ascript)[0]
print "The page is from", frontURL.split('//')[1].split('/')[0]
I’m not a big fan of the subprocess syntax, but I can live with it.
Gabe has responded to Clark’s post with a prediction that all languages for the Mac between Automator at the low end and Objective C at the high end are in danger of being scrapped by Apple. This is even more dire than his comment here a couple of weeks ago Despite the threat from sandboxing and the lack of recent improvements to AppleScript, I think he’s too pessimistic. OS X is still Unix, and Unix is a programmer’s environment. Unless Apple takes away the Terminal, we’ll still be able to write scripts.
And as for AppleScript, I still say Apple won’t get rid of it without plenty of notice and probably not without an alternative way—apart from Objective C—to handle Apple Events. Apple’s been pushing scriptability for Mac applications for too long to drop it suddenly. This is one situation for which Steve Jobs’ absence works in our favor: Apple won’t be as mercurial without him.
And if I’m wrong about all this? Well, I switched from the Mac to Linux once. If necessary, I can do it again.
