Of note, PyObjC 1.1 greatly improves support for Key-Value Observing, much finer grained threading support, NSProxy works a lot better (potentially enabling Distributed Objects), and much cleaner wrappers for structs like NSPoint, NSRect, and NSRange.
As of the 1.1 release, PyObjC is no longer available via CVS. That is because the repository has been moved to Subversion. The repository can be found at http://svn.red-bean.com/pyobjc/. Because it is a Subversion repository, that same URL can be used to browser the source, checkout the source via Subversion, or mount the PyObjC repository in the Finder and copy out any branch, tag or the trunk by simple drag-n-drop. Not only has PyObjC moved to Subversion, but the entire repository-- history and all-- was converted to Subversion via cvs2svn.
In many ways, PyObjC has hit a milestone in its evolution.
The latest BitTorrent OS X client is a PyObjC app that has clearly been well liked in the community (over 30,000 downloads from MacUpdate and highly rated, at that). Yet, nowhere in the various postings does it say it is written in PyObjC (it does mention it in release notes in passing -- thanks for the correction). That is a huge compliment in that it menas that the Author felt that PyObjC worked well enough that there was no reason why the user-- who very likely is not technically inclined-- need be aware of the technology used to construct the app. No apologies needed, it just works. Sweet.
As well, a couple of folks have indicated that they are using PyObjC to build commercial class solutions for various clients. They are billing their clients to write apps using PyObjC. Not because they think it is cool, but because it pays the bills.
This year is the 10 year anniversary of PyObjC. I think the celebration will start at WWDC and continue at O'Reilly's OS X Con.
Yeah, been quiet around here. We have a little show coming up and I've been just a little busy.
Fred has discovered the wonders of XML-RPC as a remote debugging tool. In particular, he is remotely debugging and/or monitoring a python based server process that is multithreaded.
Which spawned a second post discussing how to take snapshots of executing Python threads as a part of the remote debugging tools.
Speaking of really bloody useful modules, the process module is a far superior mechanism for launching subshelled tasks. It avoids the security problems of system() and is vastly more elegant than execve() or popen().