python scripting support

  • Hello,

    I want wo be able to make my program scriptable. Most important with
    python.

    My program is written in ObjectC in XCode 3

    I have read lots of stuff in the net.
    What is the better possibility:

    1) make it scriptable with AppleScript and use the Python/Applescript
    bridge or
    2) embed it (with the python framework) and use "Py_Initialize();" and
    "static PyMethodDef EmbMethods[] = {"

    to 1:
    - it is possible to use more than on scripting languages (appleScript,
    python, javascript)
    - it integrates in the system

    to 2:
    - I have to wrap up my classes (I didn’t found any example doing this
    with ObjectC classes, only C++)
    - I can have a tighter integration in my program
    - the program can’t be remote controlled (as with apple script)

    Does anyone has some pros/cons for both approaches?

    Does anyone have examples/explanation for the second approach. The
    applescript support seems to be quite well documented.

    Thanks in advance
    Georg
  • Georg Seifert wrote:

    > I want wo be able to make my program scriptable. Most important with
    > python.
    >
    > My program is written in ObjectC in XCode 3
    >
    > I have read lots of stuff in the net.
    > What is the better possibility:
    >
    > 1) make it scriptable with AppleScript and use the Python/Applescript
    > bridge or
    > 2) embed it (with the python framework) and use "Py_Initialize();" and
    > "static PyMethodDef EmbMethods[] = {"
    >
    > to 1:
    > - it is possible to use more than on scripting languages (appleScript,
    > python, javascript)

    The following languages are practical options for controlling
    applications via Apple events: AppleScript, Perl (via Mac::Glue) and
    Python, Ruby, and ObjC (via appscript or Scripting Bridge).
    (JavaScriptOSA is academic since nobody uses it.)

    OTOH, if your application needs to call functions in scripts, the only
    languages available as full OSA components are AppleScript and
    JavaScriptOSA. There's also PyOSA which is mostly functional, but it's
    a developer release and I wouldn't recommend it for production use.

    > - it integrates in the system
    >
    > to 2:
    > - I have to wrap up my classes (I didn’t found any example doing this
    > with ObjectC classes, only C++)

    Piece of cake with PyObjC. See <http://pyobjc.sourceforge.net>, and
    ask on the PythonMac-SIG mailing list for further advice <http://mail.python.org/mailman/listinfo/pythonmac-sig>.

    > - I can have a tighter integration in my program

    OSA gives reasonable integration, though the coupling is still looser
    (good for flexibility, at least in theory; not so good for efficiency
    since all data is passed by copy).

    > - the program can’t be remote controlled (as with apple script)

    Embedding an interpreter doesn't prevent you adding an Apple event API
    at a later date. And don't forget there are other IPC options you
    could use, e.g. Distributed Objects. Maybe not as popular for desktop
    integration, but still quite usable (e.g. DO can be used fro ObjC or
    any language with an ObjC bridge - Perl, Python, Ruby, etc).

    > Does anyone has some pros/cons for both approaches?

    In addition to the above: Apple event IPC is a well established
    standard (pro), but a bit fiddly to implement well (con). An embedded
    interpreter will be simple to add (pro for you), but your users may or
    not appreciate being required to use one particular language (possible
    con).

    If you want a specific recommendation, provide more information about
    the nature of the application and what scripters will do with it.

    HTH

    has
    --
    Control AppleScriptable applications from Python, Ruby and ObjC:
    http://appscript.sourceforge.net
  • on 5/17/08 10:16 AM, Georg Seifert at <georg.seifert...> wrote:

    > I want wo be able to make my program scriptable. Most important with
    > python.

    Why is Python most important? Because you like it and know it well? or
    because it's what the vast majority of your users use? The point is, make
    sure you choose a solution that suits your users best.

    > 1) make it scriptable with AppleScript and use the Python/Applescript
    > bridge or
    > 2) embed it (with the python framework) and use "Py_Initialize();" and
    > "static PyMethodDef EmbMethods[] = {"

    Either way can work, just depends what you want.

    Some technical limitations tho:

    1. Scripting bridge is only available (as an OS built-in) in Mac OS X 10.5
    and later. If your need to support prior OS versions, you may need to do
    some additional work with PyObjC to get things available with Python. I'm
    not sure what that would entail exactly, just pointing out that Scripting
    Bridge is 10.5 and later.

    2. If you are going to embed Python in your app, you're going to risk issues
    with the system. For instance, in one of the apps I write I embed Python. We
    built it back when Tiger was the OS and so we built against Python 2.3.5,
    since that's what was in the 10.4 OS SDK. We are able to have our app run on
    Leopard because while Apple did update the built-in Python.framework to use
    Python 2.5.1, they did ship a minimal runtime of 2.3. Now if in Mac OS X
    10.6 Apple doesn't ship a Python 2.3, my app may break. Apple's suggestion
    is basically to make your own Python.framework, embed it within your app,
    and use that. IMHO that's not ideal, but what else can you do?

    I'm actually working on making another one of my apps scriptable via
    AppleScript right now. And if you happen to be writing a Cocoa-based app,
    the Cocoa Scripting support is pretty nice for adding scripting support into
    your app. I think the advantage of the AppleScript route is that AppleScript
    is kinda the native scripting language of the OS. If your app is
    AppleScriptable, a whole world is open to you and your users, and they can
    have a great deal of flexibility... if nothing else, they could write their
    scripts in AppleScript or Python, useful if they know one language but not
    the other and saves them from having to learn a language just to write
    scripts to drive your app.  If you write in Python, it just doesn't open up
    as many doors as AppleScript does.

    While I personally like the Python language a lot and find writing
    AppleScripts to often be a masochistic exercise, the technology of
    AppleScript and how it plays into the greater OS and user experience -- I
    think -- makes it the way to go in terms of your app's scripting language. I
    think it gives the most options and flexibility, and hopefully few limits
    and/or problems.


    Just my opinion.

    --
    John C. Daub }:-)>=
    <mailto:<hsoi...> <http://www.hsoi.com/>
    "Weak mind, weak fist. Strong mind, no need for fist."
  • John C. Daub wrote:

    > 1. Scripting bridge is only available (as an OS built-in) in Mac OS
    > X 10.5 and later. If your need to support prior OS versions, you may
    > need to do some additional work with PyObjC to get things available
    > with Python. I'm not sure what that would entail exactly, just
    > pointing out that Scripting Bridge is 10.5 and later.

    While I don't have numbers, my impression is that appscript remains
    pretty much the de-facto standard for scripting applications from
    Python. It supports 10.3.9 and later, is much better designed and more
    reliable than SB, and provides a much nicer native API. Better
    documentation and dev tools too. Requires separate user installation,
    but that's easy to do.

    > 2. If you are going to embed Python in your app, you're going to
    > risk issues with the system. For instance, in one of the apps I
    > write I embed Python. We built it back when Tiger was the OS and so
    > we built against Python 2.3.5, since that's what was in the 10.4 OS
    > SDK. We are able to have our app run on Leopard because while Apple
    > did update the built-in Python.framework to use Python 2.5.1, they
    > did ship a minimal runtime of 2.3.

    IIRC the problem here is that Python 2.3 isn't officially supported on
    Leopard - it's several years old now and no longer maintained beyond
    critical security fixes. So it goes. I'd suggest updating your app to
    use 2.5.x, or even 2.6 if you wait a few more months.

    > Apple's suggestion is basically to make your own Python.framework,
    > embed it within your app, and use that. IMHO that's not ideal but
    > what else can you do?

    You can get a prebuilt framework build from python.org, and embedding
    it in your application bundle is trivial. It will add a few MB to your
    application's file size, but unless you're distributing over dialup
    that's really a non-issue. Only significant issue is supporting third-
    party modules (how to install them, where to put them), but the
    PythonMac-SIG folks will be the best ones to advise on that.

    > I think the advantage of the AppleScript route is that AppleScript
    > is kinda the native scripting language of the OS.

    Only inasmuch as AppleScript currently remains the most popular choice
    for application scripting, but that's due more to inertia than merit.
    I think Python, Ruby, bash, etc. will be more popular overall.

    For most purposes, I'd be inclined towards going the Cocoa Scripting
    route, despite its faults, but there are some situations where an
    embedded interpreter would be a better choice (e.g. if performance is
    an issue). Again, if the author wants specific recommendations, he'll
    need to provide more information on what the application does and how
    scripters will use it.

    HTH

    has
    --
    Control AppleScriptable applications from Python, Ruby and ObjC:
    http://appscript.sourceforge.net
  • on 5/18/08 4:56 AM, has at <hengist.podd...> wrote:

    >> 1. Scripting bridge is only available (as an OS built-in) in Mac OS
    >> X 10.5 and later. If your need to support prior OS versions, you may
    >> need to do some additional work with PyObjC to get things available
    >> with Python. I'm not sure what that would entail exactly, just
    >> pointing out that Scripting Bridge is 10.5 and later.
    >
    > While I don't have numbers, my impression is that appscript remains
    > pretty much the de-facto standard for scripting applications from
    > Python. It supports 10.3.9 and later, is much better designed and more
    > reliable than SB, and provides a much nicer native API. Better
    > documentation and dev tools too. Requires separate user installation,
    > but that's easy to do.

    Yeah, it's been around a lot longer and ought to work out better. But again,
    it all depends just what the original poster is wanting from scripting
    support.

    >> 2. If you are going to embed Python in your app, you're going to
    >> risk issues with the system. For instance, in one of the apps I
    >> write I embed Python. We built it back when Tiger was the OS and so
    >> we built against Python 2.3.5, since that's what was in the 10.4 OS
    >> SDK. We are able to have our app run on Leopard because while Apple
    >> did update the built-in Python.framework to use Python 2.5.1, they
    >> did ship a minimal runtime of 2.3.
    >
    >
    > IIRC the problem here is that Python 2.3 isn't officially supported on
    > Leopard - it's several years old now and no longer maintained beyond
    > critical security fixes. So it goes. I'd suggest updating your app to
    > use 2.5.x, or even 2.6 if you wait a few more months.

    Yes. The key point is that depending how you deal with embedding Python into
    your app, it could be an issue. Even if today you build against Python 2.5,
    what will Apple ship within the OS for Mac OS X 10.6 and 10.7... and how
    will that affect your app long term. So, you just have to be aware of the
    situation and consider what your app needs are, and then how you'll go about
    building your app.

    That's all.

    >> Apple's suggestion is basically to make your own Python.framework,
    >> embed it within your app, and use that. IMHO that's not ideal but
    >> what else can you do?
    >
    > You can get a prebuilt framework build from python.org, and embedding
    > it in your application bundle is trivial. It will add a few MB to your
    > application's file size, but unless you're distributing over dialup
    > that's really a non-issue. Only significant issue is supporting third-
    > party modules (how to install them, where to put them), but the
    > PythonMac-SIG folks will be the best ones to advise on that.

    In my app's case, the added size matters. A few MB here and there adds up in
    bandwidth costs over time and downloads. Just because we've got a lot of
    space and bandwidth doesn't mean we have to fill nor waste it. :-) There's
    still something to be said for being thrifty.

    But again, my intention here was pointing out some issues that the OP may
    not be aware of that may be useful in making his decision.

    >> I think the advantage of the AppleScript route is that AppleScript
    >> is kinda the native scripting language of the OS.
    >
    > Only inasmuch as AppleScript currently remains the most popular choice
    > for application scripting, but that's due more to inertia than merit.
    > I think Python, Ruby, bash, etc. will be more popular overall.

    Oh I agree. But this is why the first thing I said in my post was that the
    key thing is to look at was the users and what their needs are. If the
    majority of OP's users are Python folk, then the app and customer needs may
    be better served by a more native Python-based solution. If needs are more
    general, AppleScript may be the more flexible solution.

    Figure out user needs. Go from there.

    > For most purposes, I'd be inclined towards going the Cocoa Scripting
    > route, despite its faults, but there are some situations where an
    > embedded interpreter would be a better choice (e.g. if performance is

    Yeah, Cocoa Scripting has its faults, but they did a pretty good job overall
    at masking away much of the ugly details of AppleEvents and just building
    upon Cocoa paradigms like KVC to bring AppleScript support to an app.

    > an issue). Again, if the author wants specific recommendations, he'll
    > need to provide more information on what the application does and how
    > scripters will use it.

    I agree completely.

    --
    John C. Daub }:-)>=
    <mailto:<hsoi...> <http://www.hsoi.com/>
    Peace on the Earth, goodwill to men.
  • > Again, if the author wants specific recommendations, he'll need to
    > provide more information on what the application does and how
    > scripters will use it.

    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.

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

    And does anyone has experience with performance?

    Thanks for your replies

    Georg_______________________________________________
    MacOSX-dev mailing list
    <MacOSX-dev...>
    http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • 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
  • on 5/18/08 6:56 AM, Georg Seifert at <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.

    It seems like it, yes. I mean, if you use Scripting Bridge, you still have
    to somewhat understand the nature of AppleScript, then Scripting Bridge. If
    you're trying to minimize the learning curve for your users, a more
    Python-centric solution may be better.

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

    Maybe, maybe not. Again, I think it would depend upon just what other apps
    might be likely to be chained into the mix here.

    I personally feel that AppleScript is a good architecture to expose
    scriptability in one's app, given it's place within the Mac OS X world. But
    to choose to use AppleScript as the language to drive your scripts well,
    that's up to the scripter.

    > And does anyone has experience with performance?

    I would gather this is tough to quantify, as it'll depend a lot upon
    implementation both of how you hook up your scripting and then the scripts
    themselves. It'll be something you'll just have to determine in your own
    app.

    --
    John C. Daub }:-)>=
    <mailto:<hsoi...> <http://www.hsoi.com/>
    "...as the war machine keeps turning, death and hatred to mankind." - Black
    Sabbath
previous month may 2008 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today