on application scripting and Python (Re: on synonyms and homonyms)
on application scripting and Python (Re: on synonyms and homonyms)
- Subject: on application scripting and Python (Re: on synonyms and homonyms)
- From: has <email@hidden>
- Date: Tue, 24 Feb 2004 18:22:32 +0000
Simon Forster wrote:
app('Finder.app').home.folders['Documents'].files.name # (Python)
Would you mind telling me what Python module you're running to give
you AppleScript access?
My own: appscript.
See: <
http://freespace.virgin.net/hamish.sanderson/appscript.html>
You'll need OS 10.2.6+ and MacPython 2.3+ installed to run it.
Also, to clarify: Like AppleScript, appscript lets you do
_application scripting_, but has nothing to do with the AppleScript
language itself. The module is written in pure Python, as are the
scripts you write to use it, and appscript automatically converts
application terminology to Python-compatible identifiers. I know
folks often use the name 'AppleScript' to refer to application
scripting in general, but I think it's time to start being specific
to avoid confusion between application scripting via AppleScript and
application scripting via any other language.
Also, can you advise as to its robustness and general utility?
Ah well, you had to ask, didn't you? ;) Okay, here goes...
The module code is compact and reasonably clean and stable, so should
be reasonably reliable in itself. As for using it:
There are a few issues to know of:
1. Appscript's API has a couple minor quirks: elements are
one-indexed (Python's native zero-indexing doesn't mesh well with
AEM, so I had to choose AEM compatibility over Pythonic niceties),
and test expression (a.k.a. 'whose clauses') syntax is a little
clumsy due to Python language limitations.
2. Because this is just an AEM bridge, not a full OSA compatibility
layer, you can send Apple events from Python to applications, but not
vice-versa; i.e. there's no support for attachability and other OSA
niceties. (This'll be a separate project for another time.)
3. Appscript does not provide a Python-to-OSA eXtensions bridge, so
you can't use osaxen directly in Python. However, Python's module
support is absolutely first rate and far superior to anything OSAXen
have to offer, so you're very unlikely to miss them in practice - I
certainly don't.
4. Appscript is much more strict about terminology resources
correctness than AppleScript. This means some apps that can be
controlled from AppleScript are unscriptable or only partially
scriptable from appscript. Consider this a Good Thing, however (see
2. below), and go beat on developers to fix their bugs as you find
them. (After all, you wouldn't accept an app that had broken menus
and dialogs, would you?)
Now the good:
1. Appscript is highly dynamic; much more so than AppleScript.
Terminology keywords are converted to AE codes on the fly, not baked
into the code at compile-time as AS does. So there's no messing
around with 'tell' blocks, 'using terms from' directives, raw AE
codes, keyword collisions, and inability to control multiple
applications from a single piece of code.
2. Appscript is much more intelligent than AppleScript. While AS
ignores much of the structural information provided by application
terminology resources, appscript uses it all. Its detailed
understanding of an application's object model allows it to perform
various checks when constructing references and sending commands,
reporting malformed references, inappropriate operations, missing
parameters, etc. directly to the user, instead of raising obtuse
compilation errors or throwing the problem over to individual
applications (and we all know how poor most of them are at reporting
such errors - Cocoa apps, you know who you are!). As well as being
able to render application terminologies as convenient hyperlinked
HTML files, it also provides built-in help() methods on all
Application and specifier objects so you can view this information
directly while running code!
3. You get to use a scripting language that doesn't suck. [Sorry,
AppleScript, but you _are_ the weakest link.] Python isn't the
perfect language by any means, but the syntax is clear and
unambiguous and it's reasonably fast and very reliable in use. If you
ignore the somewhat overblown OO programming model, you should be
able to learn basic procedural programming (which is what most ASers
use anyway) in a day. There's plenty of documentation and tutorials
available online for programmers and non-programmers alike, and the
comp.sys.python newsgroup is full of friendly, helpful folk should
you need to ask anything.
If you're feeling adventurous, I'd suggest downloading appscript [and
MacPython 2.3+ if you don't already have it] and giving it a whirl.
Just bear in mind that both module and documentation are still
works-in-progress. (See the Manual.txt file and HTML documentation
for details on what's currently supported and what's not.)
Experienced scripters should find it reasonably easy to get to grips
with, though novice scripters should probably wait until the
'Introduction to Application Scripting' docs and tutorials are ready,
which should be by summer.
There's some sample scripts included, and I'm posting new ones to my
site as I write them, so why not start by playing with those? I'm a
bit busy with other work for the next few days, but should have more
time after that if you want to discuss further.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.