Re: python scripting support

FROM : John C. Daub
DATE : Sun May 18 13:06:00 2008

on 5/18/08 4:56 AM, has at hengist.<email_removed> 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:<email_removed>> <http://www.hsoi.com/>
Peace on the Earth, goodwill to men.