[Pythonmac-SIG] [ann] AppScripting 0.1.0

[has]

Bob wrote:

>aeve does the following when you do aeve.talkto('something'):
>	(1) find the application using 'something' as an identifier 
>(by LaunchServices and several other means)
>	(2) If the application's interface is not already generated then:
>		(a) gets the aete(s) from the application (by several means)
>		(b) converts the aete(s) into python modules, 
>classes, objects (respecting inheritance, etc.).  Throws them all in 
>a registry so they can be converted to/from AEDescs at the bridge.
>		(c) cache this interface
>	(3) instantiate and returns the application object mixed in 
>with a "talkto" class so that you can use it directly

Well said. Much better than I could (did!) put it.


>aeve does not ever use __getattr__ hacks and figure it out sometime later.

Don't really think of __getattr__ as a hack; at least, no more so 
than using introspection on the fly in general. But maybe that's just 
me; I dunno. That said, it'd be just as easy to implement the AS 
interface in more traditional belt-n-braces fashion if __getattr__ 
made anyone nervy:

    textedit.element('document', 0).property('text').get()

Not very attractive though.


>It does things the way that Python typically does things; members 
>are in the class __dict__, it uses normal Python class inheritance 
>mechanisms, etc. [...] This way of doing things provides some 
>significant advantages (doc generation, introspection, etc.) over 
>what you're doing.

Curious: what sort of uses might introspecting aeve's generated 
classes be put to?

Yeah, being able to generate docs by shoving stuff through an 
existing tool like pydoc would be nice, but I don't expect 
implementing my own doc generator should take too long.


To balance the advantages/disadvantages a bit: one of the nice things 
about AppScripting is that it does things the way that OSA does them 
- and OSA can do a few things that standard Python doesn't do. For 
example, to get the name of every file in a folder:

    folderRef.files.name.get()

Or to set the size of the first character of every paragraph of a 
document to 24:

    docRef.paragraphs.characters[0].size.set(24)

AppScripting gives you this behaviour for free, since all it's doing 
is mirroring OSA behaviour.


>Complicated, I'll give you that, but that's my problem as the author 
>not yours as the end user.

Well, for whoever has to maintain the library really. Dunno if you're 
hoping to get aeve into the standard MacPython distro or not, but 
this is certainly my desire for AS so KISS is a definite 
consideration for me.


>I'm not exactly sure what you mean by labor intensive,

For the machine that is, not the user. (Welcome to my wonderfully 
vague and fanciful way with words.;)


>It can take a few seconds to get the aete from some applications 
>because it has to open a connection to WindowServer, but this only 
>happens once per run and it's probably possible to optimize this out 
>(since Apple Events don't actually need WindowServer, from what 
>Apple says).

Yeah, I find it deeply ironic that a non-window-based UI should 
somehow require a window server. Be interested if this can be done.


>I'd imagine that the actual runtime performance of aeve would be as 
>fast or faster than what you're doing,

Not really a concern at this stage (premature optimisation = root of 
all evil, etc), though a quick test showed no obvious difference in 
object referencing and message sending performance. (Building the 
initial object model/accessor rules is quicker under AS than aeve, 
but like you say this isn't really here nor there in the big 
picture.) At any rate, I'd say that bottlenecks in application 
scripting tend to be in pushing lots of data through AppleEvents or 
in applications taking their sweet time to respond to messages (OS9's 
Finder was notorious for this), so I don't think either of us needs 
to be overly concerned with this.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/