Question

How do you create a playlist using Python and Scripting Bridge?

So far I have :

from Foundation import *
from ScriptingBridge import *

iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
newPlaylist = iTunes.iTunesPlaylist()

This obviously doesn’t work.

I’ve seen things for Ruby and Objective C, but I don’t really understand the language.

Answer 1

This is actually an example in the Scripting Bridge documentation. See Listing 2, “Adding an object to a scriptable application in PyObjC code”:

from Foundation import *
from ScriptingBridge import *

iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
p = {'name':'Testing'}
playlist = iTunes.classForScriptingClass_("playlist").alloc().initWithProperties_(p)
iTunes.sources()[0].playlists().insertObject_atIndex_(playlist, 0)

If this doesn’t make sense to you, there are a few different ugly things to explain…

First, SBApplication doesn’t have any member iTunesPlaylist that’s a nice subclass of SBObject. If you’ve generated static glue, ITApplication might have such a thing… but you don’t want to use static glue. So, you have to dynamically create the class object iTunesPlaylist. There are a few different ways to do that, but the easy way (assuming you know it’s called playlist in Applescript) is with classForScriptingClass_.

Next, ScriptingBridge isn’t really a native Python bridge to AE; it’s a Python bridge to the ObjC bridge to AE. So that iTunesPlaylist is actually a wrapped-up ObjC class, not Python class. That means you can’t just instantiate it as iTunesPlaylist(), you have to say iTunesPlaylist.alloc().init().

Calling initWithProperties_(p) is a nice shortcut to initializing and setting properties in separate steps.

Finally, the way the AE object model works, you can’t just “create an object”, you have create an object at some location. ScriptingBridge tries to hide this from you, but it doesn’t do a very good job. The playlist object you create doesn’t actually represent anything in iTunes yet—in fact, if you look at its type or repr, you’ll see that it’s a “future iTunesPlaylist”. You need to find an appropriate SBElementArray to insert it into, and then it will become a real playlist.

Not everything in ScriptingBridge is this horrible. But some of it is even worse. Just wait until you run into one of the areas where iTunes’ scripting dictionary is wrong…

The iTunes AE interface itself is very nice, if you can avoid using ScriptingBridge. There are three ways around that, although they may not help you.

First, there’s appscript (docs here). This is a different Python->AE bridge which is much better than SB. Here’s what the same thing looks like (relying on the default that iTunes has a default location for playlists—at the end of the list of playlists in the first library source):

from appscript import *

iTunes = app('iTunes')
p = {'name':'Testing'}
playlist = iTunes.make(new=k.playlist, with_properties=p)

And if you can’t figure out how to do what you want, but can find AppleScript sample code (e.g., at dougscripts), you can use the ASTranslate tool to write the equivalent appscript.

Unfortunately, the author of appscript has canceled the project. And with good reason—it relies on legacy APIs that Apple could remove in 10.9 (or cite to reject you from the App Store). At present, it still works fine, and a few people are keeping it alive at the github repo above, but one day, it will have to die for real. So, it may not be a good solution unless this is a personal, short-term, or learning project. (Also, specific to iTunes: 10.6.3 has a bug that affects appscript, but doesn’t affect other bridges unless you’re using them remotely. If you need to work with that version, see itunesterms for one solution.)

Of course there’s always the obvious option: do it in AppleScript:

tell application "iTunes"
    make new playlist with properties {name:"Testing4"}
end tell

The problem with AppleScript is that it’s a horrible language for everything except talking AEOM, and its equivalent of Python’s standard library is about 5% as deep and wide. But you can always use a two-language solution, in two ways. You can connect from AppleScript to other Cocoa code (e.g., Python with PyObjC) via ASOC. Or, alternatively, you can use NSAppleScript and friends to run scripts from PyObjC/etc.

The latter may be the most painful answer, but it has one huge advantage: If you use the new APIs in Mountain Lion, and your use cases fall within a certain narrow band, you can write a sandboxed app that scripts iTunes without needing a temporary exception entitlement, meaning you can sell it in the App Store.