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
