Bill Bumgarner

A friend asked me what he should install onto his Mac OS X system to most effectively learn Python. This particular person is a very experienced Objective-C and Java developer, with loads of Mac OS X specific adventures.

This post is targeted to that kind of developer.

Mac OS X ships with a perfectly usable build of Python included in the system (as long as you install the BSD package, which is enabled by default).

First, install the most recent production release of the Subversion client. That link leads to some very convenient to install packages. Alternatively, installation via Fink or DarwinPorts will also work quite nicely. Or you can build it from the source.

Next, grab a pre-compiled copy of the readline.so module. Decompress it, then copy it into the appropriate place within /Library/Python/2.3/. Interactive Python without readline is miserable.

Then grab the top-of-tree of the PyObjC repository via Subversion. The top-of-tree is almost always very stable as a result of the relatively large and high quality unit testing suite and the focus-on-quality of the developers. Once installed, the benefits are two fold. First, it will install PyObjC, including all examples, the Xcode templates, and the runtime itself. Secondly, it will install py2app which will allow one to easily package Python modules and applications, including creating Installer packages out of any standard Python module.

 svn co http://svn.red-bean.com/pyobjc/trunk/pyobjc/ 

And build/install it:

 python setup.py bdist_mpkg --open 

The above will build a .mpkg that contains PyObjC, py2app, and related resources, then open it the Installer application.

From there, it is a matter of choosing your favorite editor. Xcode, SubEthaEdit and Emacs can all edit Python quite effectively. The key is to turn off tabs. Never, ever, insert tabs into Python source -- always use spaces.

There are other editors available. I pretty much stick to a mix of Emacs with a custom setup (you'll want to grab the latest python-mode, at the least) and Xcode, with the occasional bout of SubEthaEdit, depending on mood.

For learning Python, I would start with Dive Into Python and then-- because this is aimed to Mac OS X developers-- move on to ripping into the PyObjC examples. Also, ReSTedit is a fairly decent sized Cocoa-Python application that is under active development, tends to track the latest changes in PyObjC, and has a couple of relatively complex third-party Objective-C classes integrated into the project.

That should provide a pretty decent foundation for both generic and Mac OS X specific Python development. Certainly, there are any number of other tools that one might install, varying in size and complexity.

Recommendations, corrections, and suggestions welcome.

Since giving away my iPod Shuffle to my wife a few weeks ago, I have had need of a portable storage device. Never before, but now I do. Go figure.

I have a firewire hard drive but it was either in use or largely unavailable and, even if available, I have to screw around with firewire cabling to make hook it up and then switch machines. A Shuffle would work, but iTunes is always going to fire up and ask to take over the device (if the machine doesn't already own it).

Today, I finally got completely fed up with the situation after about the fourth time I needed to move a handful of files between two machines that were otherwise isolated.

So, I headed down to the on-campus Apple store to pick up a flash drive only to discover that they were out of stock. Now, that wouldn't be that big of deal if I hadn't been in the store earlier in the day and saw three 512MB units in stock at that time. So, apparently, I'm not the only person needing this kind of convenience.

On the way home, I stopped at Office Max to pick up a random cable. They had the Lexar 1 GB JumpDrive Secure on sale for $85 with an on the spot discount of $10 and a mail-in rebate for $15 -- bringing the price to $60 (yup-- math sucked the first time around). Not bad for a 1GB USB 2.0 (the high-speed 2.0) drive.

I'm ignoring the "secure" feature. Instead, I created a sparse encrypted disk image on the device that is the same size as the device. Sparse disk images start out minimally size and will automatically grow, as needed, up to the size of the media they reside upon.

You can create the disk image from within Disk Utility or the command line. The command line will look like (this is a single command):

hdiutil create -size 1g -fs 'Journaled HFS+' -type SPARSE \

    -encryption -volname Name-Of-Volume /Volumes/FlashDrive/Name-Of-Volume

I would recommend not placing the disk image password in your keychain. The end result is a convenient, cable-less, tiny portable storage device with unencrypted and encrypted storage areas that automatically grow/shrink as your needs change. No third party drivers or software needed.

Update #1: As Eric noted, the resulting image will start out at 34MB for an empty image. That appears to be overhead related to creating the disk image. As the size of the image drops, the amount of overhead drops along with it -- to a point. To answer another question of Eric's, hdiutil compact image will recover disk space no longer used by the sparse image and return it to the underlying file system.

Update #2: Bob Ippolito suggests that journaling an encrypted disk image is largely pointless. He claims that it will increase the potential for corruption and the additional duplication of information necessary to journal the filesystem will necessarily imply less security.

Honestly, I don't really have enough information to form an opinion in regards to the likelihood of corruption with or without journaling. As for security, it is true that any repetition of data within an encrypted stream decreases security. In this case, the decrease in security is likely extremely miniscule.

But there is another reason to turn off journaling and it gets back to Eric's point about the overhead. Turning off journaling reduces the "out of the box" size of a 1GB sparse, encrypted, disk image from 34M to 26M. A significant savings.

Some more data:

FS Type	1g empty image size
HFS+ Journaled	34M
HFS+	26M
HFS	4M
MS-DOS	3M
UFS	89M

Interesting and not terribly surprising. For now, I think I'll stick with HFS+ as I have plenty of space. hdiutil can always be used to convert the image from one format to another later.