[Pythonmac-SIG] Re. [ann] AppScripting 0.1.0

[has]

Jack wrote:

>First, let me start by asking both of you to add docstrings to the
>code. I had a quick look through both aeve and AppScripting, and it's
>really hard to find your way around either of them....

On the to-do list.:) For my education, is it normal practice to put 
docstrings on everything - both private and public - or just on the 
public stuff? I've rather assumed that docstrings are supplied for 
the benefit of end users, rather than developers who can read 
comments as easily.

(e.g. In HTMLTemplate I left out docstrings and supplied separate 
user documentation which explains its use based on a simpler, 
fictionalised object model. The internal structure is actually much 
more complicated and not entirely conventional, so docstringing it 
would likely cause more confusion than anything. Thinking of doing 
the same with AS.)


>  > aeve [...] does things the way that Python typically does things;
>
>This I like, I think. It has the advantage that you should be able to
>use the standard Python introspection features on aeve objects,
>something I missed with I looked at AppScripting.

I'm still curious here about how introspection is being used, and to 
what purpose? Anyone shed some light for me? I suspect introspecting 
AS wouldn't do you much good anyway; better to read the docs to learn 
what's going on. Though knowing what you're looking for'd give me a 
better idea.


>There is a question
>of cost, though: I assume that this makes aeve startup more expensive
>than AppScripting startup, at least in theory. Right?

Yes, but as Bob points out, this can easily be made a one-off charge 
by caching and reusing the result over the length of the runtime, so 
is pretty much irrelevant.


>Note that I also particularly like this model (as opposed to doing
>everything at the last possible moment), because it leaves much more
>room for caching.

Caching's only worth doing when it actually makes a difference to 
performance. With aeve and AS any performance bottleneck lies at the 
aete parsing stage so is not too critical. Neither module suffers any 
performance problems in object referencing/event dispatching since 
that code is already well streamlined.


>And I think caching (of complete AETE interfaces) is
>where Python could gain points on AppleScript:

AppleScript does all its binding at compile-time, so doesn't suffer a 
runtime penalty from parsing terminology as aeve and AppScripting do.



>if you want to do something really simple to an application then not 
>having to read and
>parse the AETE could be a big win.

As Bob said, right now the most painful bottleneck is in having to go 
through Window Manager whenever you want to send AppleEvents. Boshing 
that would be the most worthwhile optimisation.

If reading aetes at each runtime still proves too slow for users, we 
could always pickle the parsed aete resources for reuse over 
subsequent sessions. The only times you'd then need to (re-)parse the 
aete is when a pre-parsed aete doesn't already exist for the app 
being used, or a different version of that app has been installed 
since its aete was last parsed and cached. I'm sure this could be 
automated too.


HTH,

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