PyObjC 2.0 (PyObjC in Leopard)

Leopard includes PyObjC 2.0, a huge upgrade over the 1.x series that will be hitting the public repository in the very near future (Ronald’s time permitting).

Both Ronald (who did all the work) and I (sort of) had posted previews of PyObjC 2.0. Now the full magnitude of this release can be publicly discussed.

In particular, Ronald’s post gives an excellent overview of the new features and capabilities of PyObjC.

There is a theme: “greatly tighten the integration with Mac OS X in a more consistent and less special-cased fashion”.

Read on for details:

To that particular end, PyObjC 2.0 — like recent releases of RubyCocoa — embraces the metadata generated by BridgeSupport. BridgeSupport allows a machine-readable description of APIs — be they C or Objective-C — in XML, with support for 32 vs. 64 bit differences. PyObjC and RubyCocoa use the BridgeSupport metadata o make calls from the interpreter into the native ABI on the system. Succinctly; BridgeSupport allows for data driven calls through to APIs that were previously special cased either per call site or per bridge implementation.

BridgeSupport is included with Leopard, including documentation. See the gen_bridge_metadata and BridgeSupport man pages. As well, a full-text search in Xcode’s documentation viewer reveals another chunk of documentation.

At the other end, Leopard also includes a vastly improved version of libffi. Beyond a number of bug fixes and actually having a man page now, libffi also correctly supports both 64 bit ABIs available in Leopard; ppc64 and x86_64.

Specifically, PyObjC and RubyCocoa use the BridgeSupport generated metadata to construct native calls via the FFI API.

Leopard provides metadata for most of the frameworks and CF-or-higher level APIs on the system. Not all; some APIs can’t be expressed via the metadata yet (C++, for example).

The list is quite long:

  • libSystem
  • AddressBook
  • AppKit
  • AppleScriptKit
  • ApplicationServices
  • ApplicationServices/CoreGraphics
  • ApplicationServices/CoreText
  • ApplicationServices/ImageIO
  • ApplicationServices/SpeechSynthesis
  • Automator
  • CalendarStore
  • SpeechRecognition
  • Cocoa
  • Collaboration
  • CoreAudio
  • CoreAudioKit
  • CoreData
  • CoreFoundation
  • CarbonCore
  • DictionaryServices
  • CoreVideo
  • DVDPlayback
  • DirectoryService
  • DiscRecording
  • DiscRecordingUI
  • ExceptionHandling
  • Foundation
  • ICADevices
  • IOBluetooth
  • IOBluetoothUI
  • InputMethodKit
  • InstallerPlugins
  • InstantMessage
  • JavaScriptCore
  • LatentSemanticMapping
  • OSAKit
  • OpenGL
  • PreferencePanes
  • PubSub
  • QTKit
  • ImageKit
  • PDFKit
  • QuartzComposer
  • Quartz
  • QuartzCore
  • ScreenSaver
  • ScriptingBridge
  • SecurityFoundation
  • SecurityInterface
  • SyncServices
  • SystemConfiguration
  • WebKit
  • XgridFoundation
  • WhitePages

Not all of these APIs are available directly in PyObjC. Yet. Some require a touch of glue. If “import FrameWork” doesn’t work, glue will be needed. More on the glue in a later post.

Both the metadata listed above and the tools to generate the metadata are provided without requiring the dev tools to be installed. Dev tools are necessary if metadata generation also creates a dylib that contains any bits — static inline functions, for example — that cannot be expressed purely in XML.

And, of course, it is quite straightforward to generate bridge metadata for your own Objective-C and C APIs. It is just a matter of running the gen_bridge_metadata utility against your APIs. Exceptions in the form of XML that overrides the automatically generated XML can be provided, too.

In essence, Apple is taking a bit of a different approach to embracing and supporting scripting languages to develop native applications.

Instead of trying to crowbar the scripting language’s syntax on top of whatever VM-du-jour happens to be running on the platform, BridgeSupport — and, by integration, Leopard — provides all of the metadata necessary to allow the native scripting language to be used to create native applications through a bridge between the two. Given that BridgeSupport works just fine on Tiger, this isn’t something limited to Leopard.

The metadata is intended to be a resource for use beyond bridging. Most frameworks on the system provide two chunks of XML BridgeSupport metadata; succinct and full. The succinct version contains all of the metadata not provided by the Objective-C runtime (which provides about 80% of what is necessary to do full fidelity calls in / out of Objective-C via libffi). The full version contains just that, the full metadata required to describe the APIs of the framework, including all the bits that could be gleaned at runtime.

Already, the BridgeSupport API metadata is used for more than just bridging languages. For example, Xcode offers Objective-C method name completion in standalone Python and Ruby source files — no project necessary — by leveraging the BridgeSupport metadata!

I am looking forward to seeing the imaginative ways with which developers leverage the BridgeSupport metadata. Certainly, there is more work to be done, but it should provide a very strong foundation for innovation as it is now!

Once PyObjC 2.0 move over to the public repository, I fully expect that development on 2.0 will continue beyond what ships in Leopard. As a consumer of PyObjC, it will be up to you to decide whether you want to stick with what is in Leopard or track PyObjC development.

For most folks, what is in Leopard will be just fine — it works great for building Cocoa applications.



14 Responses to “PyObjC 2.0 (PyObjC in Leopard)”

  1. Michael Tsai - Blog - BridgeSupport says:

    [...] Bill Bumgarner: Already, the BridgeSupport API metadata is used for more than just bridging languages. For example, Xcode offers Objective-C method name completion in standalone Python and Ruby source files—no project necessary—by leveraging the BridgeSupport metadata! [...]

  2. Ian Baird says:

    Bill:

    What a wonderful job you guys have done in supporting Python on the platform. This buy-in by Apple to the scripting bridge really helps win over clients who are worried about otherwise using a non-officially supported solution. Ronald has done yeoman’s work getting all of this together for what looks like a stellar release.

    I’m already using it in projects which will be shipping early next year. It’s rock-solid so far, and I can’t wait to get in deeper. Now for that 64-bit python support…

    – Ian

  3. has says:

    Sounds like an already terrific piece of kit just got even better. Really looking forwards to getting my hands on it. Major kudos to everyone who has helped to make PyObjC what it is today, and especially to Ronald for all his hard work on version 2.0; may it be a great success.

  4. Paul says:

    Thanks very much for the update, and thanks to all involved for the hard work. The radio silence was hard to bear!

    Are there plans to update pyobjc.sf.net at some point?

  5. Tyler Bye says:

    Bill:

    Will pyobjc remain the best place for docs going forward or will efforts be made to create documentation available through ADC?

    Thanks for the efforts!

  6. bbum says:

    The answer would be both. Apple will continue to refine documentation of supported technologies, of which PyObjC is now on that list! At the same time, the PyObjC community will continue to refine the documentation and examples found within the repository.

  7. bbum says:

    The answer would be both. Apple will continue to refine documentation of supported technologies, of which PyObjC is now on that list! At the same time, the PyObjC community will continue to refine the documentation and examples found within the repository.

  8. Blue Sky On Mars » Blog Archive » links for 2007-11-02 says:

    [...] bbum’s weblog-o-mat » Blog Archive » PyObjC 2.0 (PyObjC in Leopard) Python (and Ruby) support is greatly enhanced in Leopard. Cool! (tags: python macosx programming) [...]

  9. stuffonfire.com» Blog Archive » PyObjC 2.0 says:

    [...] OMG. [...]

  10. TuxJournal.net 2.0 » Archivio » Apple poco interessata nello sviluppo con Python? says:

    [...] moduli di terze parti, ma anche l’aggiunta del supporto al linguaggio per DTrace e l’inclusione del sopracitato PyObjC [...]

  11. Federico Tartaglia » Apple poco interessata nello sviluppo con Python? says:

    [...] a diversi moduli di terze parti, ma anche l’aggiunta del supporto al linguaggio per DTrace e l’inclusione del sopracitato PyObjC [...]

  12. PyObjc 2: Leopard, Python 2.5.1 and You. » jessenoller.com says:

    [...] was a completely overhauled PyObjC built-in. Including Webkit bindings, and many other things (see here and here for more details), a built-in version of twisted and many other [...]

  13. Ivan Levashew says:

    It seems that BridgeSupport becomes IDL for ObjC. I’m wondering if I can use BS to bring Cocoa to Ada too (codename AdaStep). I have a question:

    Does BridgeSupport aid inheritting ObjC classes in a foreign language? Can I inherit a class in Ada than in ObjC back again?

  14. Dan says:

    I want to develop a Mac/iPhone Cocoa/Cocoa Touch client in Objective-C that interfaces with a server built with Python. therefore…

    On http://www.macdevcenter.com, at the bottom the article “Introduction to PyObjC”, appears the following statement:

    “The next article in this series will focus on the integration of Python and Cocoa through the PyObjC bridge. In that article, a full-featured web services application will be developed using Python as the language of implementation, Project Builder and Interface Builder as the IDE, Cocoa as the GUI API, and Python’s XML-RPC library as the web services API.”

    Is that article available anywhere?

    Also the following is stated on Bill Bumgarner’s profile at http://www.oreillynet.com/pub/au/1110:

    Kindest Regards,
    Dan

    “Bill is also the project leader of the PyObjC project and is using the PyObjC module to build a full featured Cocoa client using the Python XML-RPC client library for CodeFab’s Intent.”

    Is there anywhere I can learn more about that?

Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>