Re: on application scripting and Python (Re: on synonyms and homonyms)
Re: on application scripting and Python (Re: on synonyms and homonyms)
- Subject: Re: on application scripting and Python (Re: on synonyms and homonyms)
- From: Simon Forster <email@hidden>
- Date: Wed, 25 Feb 2004 09:33:40 +0000
Many, many thanks for this. I've been mucking with Python on and off
for a few months now and like it. I'm a lazy coder and Python seems to
fit with my laziness :-)
Given the above, you may understand why I have a love/hate relationship
with AppleScript! A couple of lines of code will control an application
to do something which would take _serious_ coding by most other methods
- but then you've got to futz with an obscure, English like syntax.
As so often in life, a great strength is a great weakness. One of
AppleScript's greatest strengths is a the approachability of its
syntax. But after a while you become frustrated with its idiosyncrasies
and inherent limitations.
AppleEvents and Python sounds good. I plan to investigate further.
Thank you.
Simon Forster
_____________________________________________________
LDML Ltd, 62 Pall Mall, London, SW1Y 5HZ, UK
Tel: +44 (0)70 9230 5244 Fax: +44 (0)70 9230 5247
_____________________________________________________
On 24 Feb 2004, at 18:22, has wrote:
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/
Simon Forster
_____________________________________________________
LDML Ltd, 62 Pall Mall, London, SW1Y 5HZ, UK
Tel: +44 (0)70 9230 5244 Fax: +44 (0)70 9230 5247
_____________________________________________________
_______________________________________________
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.