[Pythonmac-SIG] appscript terminology caching

[Bob Ippolito]

On Oct 19, 2004, at 15:15, Eric Nieuwland wrote:

> On 19-okt-04, at 17:51, Bob Ippolito wrote:
>> On Oct 19, 2004, at 11:44, Eric Nieuwland wrote:
>>> Would adding a parameter with values 'always', 'if there is none', 
>>> 'never' to control when the terminology is to be generated do the 
>>> trick?
>>
>> How is that better than having the option to explicitly "freeze" a 
>> terminology into an importable python module?
>>
>> Remember - the ONLY reason to cache terminologies is to save ~0.5 
>> seconds per run.  If you have a script that you need to run very 
>> often or redistribute, you can spend a minute to freeze the 
>> terminology.
>
> Well, why not optionally freeze the terminology in advance into a 
> specific area like .../site-packages/terminology. Let's call it a 
> cache to keep has happy.
> Then, from your program you could use (extending has' example):
>
> 	itunes = app('eppc://20.20.20.20/iTunes', 
> usingtermsfrom='iTunes.app', terminology=X)
>
> where X is:
> 	frozen		to get Bob's preferred system
> 	cached		to get has' idea
> 	application	to always obtain the terminology from the current 
> application (possibly putting in the cache)

But *why* put it there?  Why not with your application?  You need admin 
access to touch site-packages, and considering that multiple 
terminology-using applications and possibly multiple users would use 
the same cache area makes it rather problematic.

I'm not at all convinced that it's worth doing.  For the cases where 
you need the efficiency, you freeze it to a particular python module 
named whatever you want, wherever you need it to be.  This has the 
added bonus of being discoverable by dependency walking (mostly 
packaging) utilities since you will be importing it explicitly.  
Otherwise, you look it up dynamically and take the speed hit.  Why make 
it more complicated?

The only situation I can come up with where you would really notice is 
if you had some throwaway python script that you were spawning a whole 
bunch of times to do something (a la shell script).  The solution is to 
not do that.  Make the script long-running and take a bunch of 
parameters on argv or from stdin, or make it a module and use it 
directly from the calling script (assuming its Python as well).  Either 
way will be a whole heck of a lot faster because (a) you've make the 
terminology lookup constant time (b) you've made the python interpreter 
startup/shutdown constant time.

-bob