[Pythonmac-SIG] appscript dead?

[Kevin Walzer]

On 3/8/12 10:05 AM, Christian Prinoth wrote:
> Hi,
> Â  I just learned that appscript development has been halted. I use it a
> lot, especially in scripts that automate interactions between Office and
> various other aspects of OSX. Does anyone know if there is any
> alternative coming up?
> More generally, is there an official Apple roadmap on scripting in OSX?
>

First, a caveat: while I haven't used the appscript library for its most 
popular use case (sending Apple Events to other scriptable apps from 
Python), I have made extensive use of has' work in making my own Python 
apps scriptable (via the "aemreceive" module in the appscript source 
tree), and I've also done some low-level work in modernizing bindings 
for AppleScript via another scripting language (Tcl).

As I understand it, has decided to halt appscript development because 
Apple has recently categorized the low-level AppleEvent API's that 
appscript depends on as "legacy" API's. See this post in the 
"applescript-implementors" mailing list for details:

http://lists.apple.com/archives/applescript-implementors/2010/Jan/msg00044.html

Out of an abundance of caution, has now discourages use of appscript for 
new projects: "As appscript cannot be ported to the Apple-sanctioned 
Cocoa APIs, all cautions and caveats that apply to legacy OS X APIs 
effectively apply to appscript as well."

I understand his caution, but I think you are still perfectly safe in 
using appscript, even going forward, as long as you are comfortable with 
using it as an essentially complete and mature library that will not 
undergo further development, in part because it no longer needs much 
refinement.

My more positive assessment of the status of the Apple Events API rests, 
in part, on the language that the Apple engineer in the link above uses 
to describe it: "legacy," "superseded," but NOT the kiss of death: 
"deprecated."

"Deprecated" means that Apple has marked the API not only for no further 
development, but eventual removal from the system.

"Superseded" and "legacy" are a bit different in their emphasis: as I 
read them, they are older API's that are no longer promoted or developed 
much, but are not going to be removed in part because they are too 
foundational/critical to the system.

As the Apple developer in the link above points out, the older "legacy" 
API's are still the basis of the shiny new Cocoa-based API's that Apple 
is now promoting for Apple Events. Apple is trying to steer developers 
to the newer API's for common functions, but the older, "legacy" API's 
are still there because they are the foundation for everything else.

I've done some work with those low-level API's, and they are not fun to 
work with. If I were a Cocoa developer I would definitely use the 
higher-level stuff. But to *implement* the higher-level stuff (whether 
it is appscript, a more Cocoa-centric approach to Apple Events, or 
Tclapplescript, the library I've worked on), sometimes it's necessary to 
get your hands dirty with the low-level bits.

The biggest risk of calling these API's "legacy" is that eventually 
fewer developers will understand how they work, and there will be less 
innovation along the lines of appscript. That's a real concern, but it 
still falls short of active deprecation and removal by Apple.

To bring this back to your specific questions:

1. I am not aware of any significant change to AppleScript coming up. 
It's still there and still promoted by Apple.
2. Apple typically doesn't release a "roadmap" unless they are 
*actively* trying to steer developers in a specific direction. Removing 
64-bit support from Carbon is an example of this. Marking the AppleEvent 
API as "legacy" is not, in my view.
3. There's no real alternative to appscript in Python, unless you shift 
to running AppleScripts via a shell command (osascript) or use one of 
the "approved" Cocoa API's via PyObjC. I'm not sure either of these 
approaches buys you anything that appscript does not.

Hope this helps,
Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com