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
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Reply via email to