Re: python scripting support

FROM : has
DATE : Sun May 18 22:47:04 2008

Georg Seifert wrote:

> I will specify my needs:
>
> - Most of my users most likely know python better than AppleScript.
> They will most likely use it to access and modify the model.
> - The scripts need to do quite processor intensive operation. e.g. My
> model contains a three structure with +20000 leafs.
> - the ability to install custom modules is not to important as I
> provide a plugin interface for bigger projects.
>
> I think this speaks for the embedding solution.


Given the performance requirement, I would recommend providing support 
for interpreters to be hosted in-process, thereby avoiding the 
additional overheads of inter-process messaging.

As for how to implement it, while the OSA API does allow your 
application to host OSA languages such as AppleScript and PyOSA, given 
your users' preference towards Python, the lack of a production-
quality Python OSA component means that the OSA route is less than 
ideal. In addition, an embedded Python interpreter can be coupled more 
tightly than an OSA language component since PyObjC uses comparatively 
cheap and simple proxy objects to represent Python and ObjC objects 
across the bridge, allowing you to expose Model objects directly to 
scripts and vice-versa. [1]

BTW, don't forget that you can always add an Apple event API later on, 
should users need to control your application from other processes as 
well. Or even a Distributed Objects API, if you don't mind going a 
more obscure (but still quite serviceable) route and don't need 
AppleScript compatibility.


You might also consider providing a general bundle-based ObjC plug-in 
API and possibly implementing your Python support as a PyObjC-based 
plug-in for that, giving users a bit more flexibility over what 
language to use. e.g. See Gus Mueller's VoodooPad which provides an 
ObjC plug-in API into which interpreter plug-ins for Lua and Python 
can be added.


> But it could also be helpful to access other apps from within the
> script. This would be easier with applescript, isn’t it?


Accessing other applications from within your embedded interpreter can 
be done via appscript/Scripting Bridge as long as the relevant modules 
(py-appscript/PyObjC) are included or can be user installed. (I'd 
recommend appscript, of course.)


> And does anyone has experience with performance?



I don't, but ask around (e.g. Gus Mueller, the PythonMac-SIG mailing 
list).

HTH

has

[1] Apple event IPC passes primitive values such as strings and lists 
by-copy and relies on object specifiers (which are a bit like XPath 
queries) to identify complex objects that can't cross the bridge, 
which might be a bit more flexible, but not as cheap or simple.
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net