[Pythonmac-SIG] Re. [ann] AppScripting 0.1.0
hengist.podd at virgin.net
Thu Nov 20 19:02:23 EST 2003
>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
>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
More information about the Pythonmac-SIG