Python with GUI on Mac

6.30: summary:
. after seeing David Mertz's
Text Processing in Python/SECTION 3
/Platform-Specific Operations,
I'm seeing Python has a Carbon API,
which you'll now see is deprecated,
so, I wondered if there's a Cocoa API now .

. other than extending and embedding C,
python is not really supporting cocoa:
. the latest python version does offer
platform-specific modules
but only for Windows and Unix
(unix does includes mac and any
Cocoa binaries that are runnable from the shell,
so our access core services
is by feeding text to a shell?! ).

. the best idea I found was ObjP:
-- much less complex than PyObjC --
it's a code generator that helps with both
embedding python into obj'c,
and extending python with C
from which you can use obj'c .
. if you'd still rather use PyObjC,
there is support for it in xcode 4 .
(see Xcode4CocoaPythonTemplates)

. a future idea I found from this search
was a python equivalent to Apple's MacRuby:
instead of being a bridge to cocoa,
it would have Python implemented in Cocoa
-- just like Jython is impl'd in Java . Mython ?

6.30: AppleScriptable or stay with Python?:
. mac's vision for scriptable app's
revolves around the use of AppleScriptObjC,
which expects you to write your tools in obj'c,
and then compose tools using AppleScript .
. obj'c can compile and run AppleScripts
by using NSAppleScript .
. Python can do the same with osascript
-- call AppleScripts from python --
or NSAppleScript -- build & run it in Python .
. see Designing for Scriptability
about ensuring your interface language
fits in with AppleScript ...
and before you give up, consider this:
many of your users
might rather reuse your code with
Apple's Automater or Applescript Editor
than with python's tools .

6.29: web.cyb/dev.py/interfaces to cocoa:

ObjP is python-obj'c bridge simpler than PyObjC:
Virgil Dupras 2012-01-20

Two years ago(2010), Dupras had used PyObjC
to embed Python in Objective-C;
however,
pyobjc-core has over 5,000 Python SLOC
[source lines of code]
and over 55,000 Objective-C SLOC,
not counting tests
for dynamically dispatching function calls
between Python and Objective-C .
Then, in January (2012)
he started getting report of weird crashes
which he could never reproduce;
The problem was that he didn't know
where to start the bug hunt
because of his inability to work within
PyObjC's codebase.

So, out of curiosity for its feasability
and to know if it was going to fix the crashes,
he started working on something
simpler than PyObjC:
ObjP would generate source code for static wrappers
which would simply use Python 3.2 's C API.
There are two types of wrappers it can generate:
# p2o: Python -to- Objective-C,
# o2p: Objective-C -to- Python .
simplicity is reliability:
. why wrap the whole Cocoa framework,
(way too many things to support)
when you can simply generate
bridges to your own code ?
. ObjP's source is at bitbucket .

PyObjC support in xcode 4:

With the move to Lion,
avoiding Xcode 4 was no longer an option.
if you opened a PyObjC project in Xcode 4.3,
you found that Xcode/IB integration worked:
— you could bind UI objects to Python .
So working on existing projects using Xcode 4.3
seemed to be no problem.
But starting a new PyObjC project was difficult.
Xcode 3 had some project templates
for creating “Cocoa-Python” applications;
but, Xcode 4 changed the format of templates,
and then the Cocoa-Python templates for Xcode 3
did not work with Xcode 4.
So gregneagle @ managingosx.wordpress.com
created Xcode4CocoaPythonTemplates !

7.16: news: PyObjC still active:
Ronald Oussoren Jun 14:

I'm working on a new release of pyobjc,
either later this month or just after
the release of osx 10.8.

6.30: web: PyObjC adding a playlist to iTunes:

from Foundation import *
from ScriptingBridge import *
iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
p = {'name':'Testing'}
playlist = iTunes.classForScriptingClass_("playlist"
    ).alloc().initWithProperties_(p)
iTunes.sources()[0].playlists().insertObject_atIndex_(playlist, 0)

Mac Python scripts with a GUI

There are several options for building
GUI applications on the Mac with Python:
# PyObjC
. a Python binding to
Apple’s Objective-C/Cocoa framework,
# Tkinter
-- standard Python GUI toolkit,
based on the cross-platform Tk toolkit
An Aqua-native version of Tk
is bundled with OS X by Apple .
# wxPython
(c++ and looking native)
# PyQt:
(c++, not quite as native, but friendlier).
[7.16: they forgot to update list:
# Pyglet:
a cross-platform, BSD-licensed,
OpenGL-windowing and multimedia Python library .
The OS X layer is using Cocoa ! ]

. Pythonmac-SIG Archives .
. MacPython wiki .

. many mac-specific packages
were removed from python 3.0:
eg, the FrameWork has pretty much stopped,
now that PyObjC is available for
full Cocoa access from Python .

OSA for Python:

. the current implementation of the
Open Scripting Architecture for Python,
(OSA originally supported only AppleScript)
allows you to control scriptable applications
from your Python program,
and with a fairly pythonic interface.
...
The aetools module uses the Carbon interface
[ hence this work is obsolete because Carbon is .]
...
Development on this set of modules has stopped.
For more up-to-date implementation of
AppleScript support for Python,
see the py-appscript project:

... [ that too is now unsupported :]

appscript is no longer developed or supported:
Apple declared the Carbon Apple Event Manager
a legacy API in Mac OS X 10.6,
advising it not be used for new development.
As of Mac OS X 10.7,
the low-level Cocoa API (NSAppleEventDescriptor)
still lacks essential functionality
(e.g. the ability to send Apple events)
while the Cocoa API (Scripting Bridge)
is too flawed and limited to be a viable
foundation for an appscript-style wrapper.
As appscript cannot be ported to the
Apple-sanctioned Cocoa APIs,
all cautions and caveats that apply to
legacy OS X APIs
effectively apply to appscript as well.
. it is recommended that users adopt
Apple-supported solutions where practical,
-- Apple's Scripting Bridge for Python --
or IPC mechanisms such as sockets
and Distributed Objects .

AppleScriptObjC -- cocoa apps written in AppleScript:

AppleScriptObjC lets you write classes in AppleScript
and use all of the Cocoa framework
from AppleScript.

AppleScript Studio was replaced?[ 2010 ]

. AppleScript Studio was nice because
it was fairly simple while AppleScriptObjC
requires you know Cocoa,
and people familiar with Cocoa
can already use Scripting Bridge,
so who is the target audience ?
... more advanced AppleScript users,
basically. That said,
it may have some appeal to other developers
who need to do a significant amount of
application automation.
Scripting Bridge (SB) is less capable
than AppleScript (AS)
and much more prone to
application compatibility problems;
plus it lacks documentation and tool support .
Not exactly an ideal replacement for AS.
. incidentally,
ObjC-appscript is significantly better than SB,
though even appscript isn't 100% compatible
with the huge spread of scriptable apps out there.
In both cases, it's actually somewhat unpleasant
to write app scripting code in ObjC
using either of these bridges,
due to the verbosity of the APIs
and the quantity of chained method calls involved
(which ObjC syntax is the world's worst for).
So if you have much
app scripting-specific code to do
within a larger ObjC-based application,
you may find it easier to implement that portion
with AppleScriptObjC providing the necessary bridging
to the rest of your app.
Plus there's the usual speed-of-development arguments
for very-high-level interpreted languages
over a not-so-high-level compiled language
such as ObjC,
although AppleScript probably isn't the best example
for making that case.

"( AppleScript becomes a first-class citizen in the Cocoa world

.... a short tutorial to get you started using
AppleScriptObjC in Xcode.)

"( It's a PyObjC-style bridge introduced in 10.6

with project templates included in Xcode 3.2.
Its presence (or absence) in Xcode 4
should tell you something. )

osascript -- call AppleScripts from python

. Python scripts can use osascript
via the subprocess module .
. see (man osascript) in mac's terminal .

NSAppleScript -- build and run AppleScript from Python

. NSAppleScript class can be used to
load existing AppleScript files
or compile AppleScript code from scratch.
While it is possible to dynamically
generate AppleScript code and execute it,
that approach is subject to all the usual dangers of
arbitrary code evaluation,
including poor performance and security holes.

Apple's support for scripting 2010
robbieduncan Jan 7, 2010:

So it seems that as of a recent version of
XCode or perhaps OSX 10.6,
AppleScript Studio (ASS) is no longer available.
Instead there is a new thing called AppleScriptObjC
that lets you write classes in AppleScript
and use all of the Cocoa framework from AppleScript.

kainjow Jan 7, 2010:

. good if your app mainly deals with scripting,
and you need some basic UI work,
but, ASS was nice because it was fairly
simple and straightforward for scripters.
However, AppleScriptObjC requires you know Cocoa,
and people familiar with Cocoa
can already use Scripting Bridge,
so I'm not sure who the target audience is.
Plus, Apple seems to have a problem
maintaining support for non-Obj-C languages.
Java got killed,
and SL doesn't have a project template for
Ruby/Python anymore,
so I'd be hesitant to put any
long-term investments in this.

hhas  Jan 8, 2010:

JavaCocoa got killed for the same reason
ASS [AppleScript Studio] is on its way out:
it was a hand-tailored bridge
between two very disparate systems,
which meant the cost of
developing and maintaining it
and the difficulty of
making it both capable and reliable
exceeded the benefits it provided
and the number of users it attracted.
. Apple dropped the PyObjC and RubyCocoa
project templates from Xcode
as they were a hassle for them to maintain.
Considering these templates are crap anyway,
can't say I miss 'em myself.
. PyObjC is quietly trundling along,
and I believe a Python 3 version is in the works.
MacRuby should rock for Cocoa development
as it's a Ruby that runs directly on top of ObjC
rather than a bridge between separate
Ruby and ObjC runtimes .

[7.16:
. that's likely why Apple gives Ruby
more of a spotlight than Python:

"(Creating a bridge between two languages
can be complex and come with
certain costs in performance and true integration.
Apple's open source project called MacRuby
aims to address these problems.
[. before Apple's MacRuby there was ...]
RubyCocoa, implemented as a bridge
between the Objective-C runtime
and the official Ruby interpreter.
. that bridge must be crossed
every time you talk between
Objective-C object and Ruby .
All objects must be converted
from one typing system to another
and messages must be forwarded
-- costly if done too often.
The goal of the MacRuby project is to
address these and other challenges
by providing an implementation of Ruby
on top of core Mac OS X technologies
such as Objective-C runtime,
the generational garbage collector,
and CoreFoundation.
In MacRuby, all classes are Objective-C classes,
all methods are Objective-C methods
and all objects are Objective-C objects.
In essence, the bridge disappears.
Ruby is implemented directly on top of
the Objective-C runtime.
More specifically,
MacRuby’s fundamental data types such as
String, Array, and Hash
are re-implemented on top of their
CoreFoundation counterparts
(CFString, CFArray and CFDictionary,
respectively).
All strings created in MacRuby
are native Cocoa strings
and can be passed to underlying C
or Objective-C APIs that expect a Cocoa object,
no conversion occurs.
This implementation detail also implies that
strings in MacRuby are UTF-16 compliant
by default.
MacRuby is also re-entrant, meaning it can be
called into from multiple threads safely.
Threads created in MacRuby are always native threads.
Finally, MacRuby uses the Objective-C garbage collector
to reclaim unused memory.
The advantages of the Objective-C collector are:
# its generational nature performs fast collections,
# it doesn’t interrupt the current process
while collecting memory
as all collections are done in a separate thread. )

Jython did this for Java;
anybody for developing Mython for Mac ?
Apple points out that porting Ruby
was particularly easy because
it has the same smalltalk roots as obj'c .
Geoffrey Grosenbach 2009:

Unlike PyObjC, MacRuby objects can
inherit directly from Objective-C objects
and add functionality to the built-in classes
while running at near-native speed.

]-7.16