[Pythonmac-SIG] [ann] AppScripting 0.1.0

[Bob Ippolito]

On Nov 19, 2003, at 10:23 AM, has wrote:

>> On Nov 19, 2003, at 4:11 AM, has wrote:
>>
>>> Jack wrote:
>>>
>>>> Was this done in parallel, or are there specific things you don't 
>>>> like about aeve?
>>>
>>> Aeve constructs scripting interfaces in much the same way as 
>>> gensuitemodule, assembling and compiling source code to create a 
>>> bunch of classes and commands to represent the classes and commands 
>>> listed in an application's dictionary. This works, but it's rather 
>>> complicated and labour-intensive, and it fills your site-packages 
>>> folder with a ton of application-specific gsm-generated modules 
>>> which seems a bit untidy.
>>
>> This isn't true at all!  aeve never ever writes a file to disk unless 
>> you're running the suite generator or doc generator.  The compiler 
>> compiles directly to in-memory Python modules (creates 
>> classes/modules/etc on the fly without exec/eval).  The introspector 
>> and doc generator run *after* this merely by introspecting what had 
>> been created.
>>
>> gensuitemodule does work as you describe, though.
> Bob, stout fellow! Do not panic(!), for those are not your toes that 
> lie now on the floor! <BANG> <KER-POW> <RICCOCHET> Oh, there goes my 
> other foot. Damn, now I fall over.
>
> Clearly a fault in the pre-alpha translation from Gobbledygook to 
> Incomprehensiblese. Yes, I did describe the GSM modus-operandi in 
> detail (which aeve doesn't follow) when I should've stuck sensibly to 
> the abstract (where it does). Perhaps something like:
>
> "Aeve constructs interfaces in much the same way as gensuitemodule, 
> assembling a bunch of custom classes and commands to represent the 
> classes and commands listed in an application's dictionary. This 
> works, but it's rather complicated and labour-intensive."
>
> Please to beat me with competent editorialship, your forgiveness I 
> hope. Foolish,

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

aeve does not ever use __getattr__ hacks and figure it out sometime 
later.  It does things the way that Python typically does things; 
members are in the class __dict__, it uses normal Python class 
inheritance mechanisms, etc.

aeve can do some AppleScript style late evaluation if you dereference 
from the class instead of the instance.  This will be improved with the 
next major release.  The next major release will also flatten it to a 
2-level namespace (app->name) instead of the current 3-level namespace 
(app->suite->name) which should fix all of the "aeve can't talk to this 
application" bugs in one fell swoop.

I would not say "much in the same way as gensuitemodule", it's *very* 
different from how gensuitemodule works.  A much more accurate 
description is that aeve is PyObjC for Apple Events.  It can spit out 
actual python files like gensuitemodule does, but that is primarily for 
debugging the core (so I could see/tweak what was generated) and fixing 
broken interfaces (which is better done at runtime once you know what 
to fix).  This way of doing things provides some significant advantages 
(doc generation, introspection, etc.) over what you're doing.

Complicated, I'll give you that, but that's my problem as the author 
not yours as the end user.  I'm not exactly sure what you mean by labor 
intensive, it's not hard to use, and it takes a trivial amount of time 
to create the interface (which is then cached).  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).  I'd imagine that 
the actual runtime performance of aeve would be as fast or faster than 
what you're doing, since it does most of the work up front and pushes 
more of the work "more directly" to Python as it does not use 
__getattr__ and such, but that still doesn't matter.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031119/c862ab6d/smime.bin