I couldn’t find anything on the web that attempted to teach Python to readers who already knew JavaScript, so I thought I’d give it a shot, since a number of my friends at Mozilla don’t know much about Python but know JavaScript incredibly well. The languages actually aren’t that dissimilar—in fact, some of JavaScript’s latest features have been borrowed directly from Python.

Aside from focusing on differences and similarities between the two languages, I also try to explain Python’s design philosophy a bit, to give readers a context for why things work the way they do.

You can read the tutorial here.

Since moving to Mozilla, I haven’t had a ton of time to work on Enso, the commercial product turned open-source project that I worked on at Humanized.

One of the things I’ve been learning about at Mozilla, though, has been getting into the habit of writing about what I’m working on. We didn’t do this much at Humanized, at least not until the first few months of 2008 when we started designing openly. I’ve found that this openness is really helpful; just taking a little while to reflect and write out my thoughts forces me to really think through what I’ve been working on, which in and of itself can help untangle myself from the challenges I’m facing and give me a fresh perspective. And the feedback one receives from the community can be even more helpful (as long as one knows how to deal with poisonous people—which, fortunately, I haven’t seen any of yet).

One of the things I’ve been neglecting to talk openly about for the past few months, however, has been Enso. There’s a lot that I’d like to write about, because there’s been a lot going on with Enso. I’m going to focus this post on a basic status report, though, so as to lay out a road map for what I’ll write about in the coming weeks.

A Brief History of Open-Source Enso

Back in December of 2007, I bought a new MacBook Pro, and over the holidays I learned some Objective-C, read about OS X internals and hacked the commercial version of Enso to work on my new computer. This was a lot of fun: Apple’s developer documentation was a pleasure to read, and I found that I really enjoyed programming in the Cocoa framework. And because Enso was built with open-source technologies in mind, getting it to work on the Mac wasn’t that hard; aside from Python, we used Cairo for all our graphics work, so most of our underlying libraries were already cross-platform.

The thing was, in order to get the basics working on OS X, I really had to cut off a lot of Enso’s limbs—in particular, a lot of fault tolerance mechanisms that made Enso such a hassle-free experience on Windows. We spent an enormous amount of time on these mechanisms, which in some sense is part of why Enso didn’t appear to gain many features since its initial launch: much of our time was spent doing things like fixing bugs that occurred on certain system configurations; adding support for Vista and other families of Windows; allowing Enso to be installed and used by a user who didn’t have administrative privileges; supporting better internationalization; fixing issues with the licensing system and our fully transparent auto-update system (prompting the user to update Enso was too inhumane for us, as were existing licensing frameworks); and building a very basic extensibility mechanism. Such things sometimes made us feel like we were really building a whole new platform for software delivery rather than the actual software that we wanted to build.

In other words, we ended up re-inventing slightly more user-friendly versions of the wheel for a lot of things, and that ultimately cost us a lot of time. The end result was what I still believe was a pretty solid and unusually humane product for the Windows platform, but by the time we’d finished doing everything, a lot of the parts of our software that handled the edge cases were quite coupled to Windows—which is to be expected with any software that breaks out of the traditional application paradigm as much as Enso does. While the original architecture of the software was designed with platform independence in mind, the final production version had a number of components that were highly specialized for Windows, and even a few that were only applicable to Windows.

Getting the OS X version to the point that the Windows version was at would’ve taken a very long time. On top of that, Enso’s extensibility mechanism was really basic—because it was only really intended for in-house use, there wasn’t any suppport for features like dependencies or C Python extensions, and packaging extensions was a relatively lengthy and cumbersome process. Power users and Python programmers, our target audience for a young open-source Enso, wouldn’t be very pleased with any of this. The commercial version of Enso behaved much like an application that happened to use a fairly limited embedded Python interpreter; we wanted the open-source version to be more like a Python package that behaved like any other Python package, and worry about the details of packaging things up for grandma later.

So when we open-sourced Enso, we decided to start fresh. This didn’t mean writing everything from scratch, but it meant constructing a new fully cross-platform Enso in the open, moving in code from our old codebase as necessary, and opting for using—and potentially improving upon—existing open-source solutions rather than reinventing wheels when the community decided it was appropriate.

Where We Are Now

The early progress on Enso, which occurred shortly after we open-sourced it, was quite impressive. Guillaume Seguin jumped in and ported Enso extremely quickly—I believe it took only a day or two of back-and-forth emails between us—while Jono DiCarlo got things up and running on Windows and I got the OS X port working. It’s now possible to check out the project, follow the README, and get Enso running on any of the platforms.

Depending on your platform and experience with C compilers, however, that may or may not mean a whole lot. Linux is by far the nicest in this regard: if you’re on Ubuntu or another distro with apt-get, you can just fetch python-cairo, python-gobject, python-gtk2, and python-xlib and you’re done. You don’t even need a compiler.

OS X is the second easiest; in early May, I committed a change that made it so that only SCons and Apple XCode Tools are needed to build Enso. (Previously, the developer was left to their own devices to build a quartz-enabled version of Cairo, which usually involved MacPorts or Fink.)

Windows, as usual, is terrifying. As is the case with creating any Python C Extension in Windows, you have to compile Enso using the exact version of Microsoft Visual Studio that was used to build your version of Python. For Python 2.3, 2.4, and (I think) 2.5, this means using MSVC 2003, which Microsoft doesn’t even sell anymore.

Where We’re Going

Right now we just want it to be possible for people to get, use, and make commands for Enso easily—that is, without having to install a C compiler toolchain.

The first step is to get Enso to a point where we have downloadable, pre-built binaries for all platforms that need it (i.e., OS X and Windows). I’ve already done this for OS X, and will blog about it later. Windows is the place that needs the most help here, though; since all the original core developers of Enso are now on Macs, there’s ironically no one left to dogfood Enso on Windows and make sure that it works there. Any volunteers for working on this would be hugely appreciated.

The next step after that is to create and document a simple framework for writing and distributing cross-platform Enso commands. I’ve written something called scriptotron, currently in the Enso tree at enso/contrib/scriptotron, that I still need to document and blog about, but it’s not perfect. I’ve also got all of the scriptotron commands I’m using from day to day in my HG repository, but I need to document those, too.

Once these tasks are done, we should be able to introduce Enso to the Python community.

After hearing Chris McAvoy drunkenly wax poetic on how programmers should be more open with the stuff they write—McAvoy himself keeps a lot of his code in a public works repository on Google Code—I decided to work more openly too. So a month or two ago I set up a Mercurial repository at hg.toolness.com and have been regularly pushing a lot of my one-off projects to it. Most of the projects on there don’t mention anything about their license, though, and I’m not sure what to do about that. I hate legal stuff.

I just found out that my hometown of Columbus, Ohio, is holding a Python conference.

This is really cool. I encourage anyone in the area who is interested in computer programming or knows anyone who is to spread the word about this. Aside from being a really fun and easy language to learn and use—it’s simple enough to be taught to children—it’s also powerful enough to be widely used in the industry (for instance, it’s the flagship language of the recently-released Google App Engine).

For those who are unfamiliar with the language, xkcd describes it pretty well, too.

Something that recently occurred to me is that the only operating system that doesn’t come with Python pre-installed on it is Windows.

While Linux and OS X both view Python as essentially a first-class development platform–i.e., as something that shrink-wrap applications can be built on–Windows does not. Instead, it’s generally expected that a Python-based Windows application be “frozen”: bundled into a self-contained package that includes a copy of the Python interpreter and whatever libraries it uses, which are private to the particular application. While this ensures that the application will function as expected and not run into “dependency hell”, it also results in a relatively large download–distributing a simple “Hello World” program is at least a megabyte in size, and makes extending the program’s functionality more difficult.

During the summer of 2007, I made simple Python-based tool for some friends who played World of Warcraft; for those that played on the Mac, the situation was easy because their computers already had Python on them. For the Windows users, however, I was faced with the dilemma of either “freezing” the program into a fairly large download which would be difficult to test and update, or making my friends download the Python installer from python.org and running my Python script from source. Either solution seemed too cumbersome.

So instead, I opted for a different solution: I’d create a tiny executable that would first check for the existence of a Python installation on the end-user’s system. If Python was already installed, the executable would simply extract a Python script from itself and run it. That script was much like ez_setup.py; along with a few tricks, it essentially ensured that my friends would transparently auto-update to the latest version of the tool whenever they launched the program.

If there was no Python installation on the end-user’s system, however, the executable would simply transparently download the latest Python installer from python.org, silently install it on the end-user’s system without any prompting, and then proceed as outlined above.

So, in other words, a small executable file–only about 50k in size–was essentially responsible for “bootstrapping” my program by downloading and silently installing Python if necessary, and then downloading and running the latest version of my program’s source code. This ultimately meant that the user would be able to run a self-updating Python program from a tiny executable without having to click through any installation prompts or dialog boxes.

I’m glossing over a few details here and there are definitely some holes in my implementation–for instance, if the user uses a web proxy, they’re hosed–but I thought the general idea was interesting.

The source for the executable was compiled using the Nullsoft Scriptable Install System, along with its InetLoad plug-in. The source file is below for those interested.

Read the rest of this entry »

At yesterday’s Chicago Python User Group (ChiPy) meeting, I gave a presentation on the Python pickle module; I’d always been curious in the internals of how serialization works “under the hood” and wanted to learn enough about it to give a talk that was accessible to Python newcomers and veterans alike.

I’d like to thank Robert Zeh of GETCO for hosting the meeting, and everyone for attending–we had a great turnout. Jono DiCarlo gave an awesome presentation on a video game he made with his 7-year old sister, Christopher Allan Webber showcased a really cool animation framework he created called PyStage, and Steve Githens gave a lightning talk on OpenOffice.org’s latest support for Python scripting.

I’ve posted the slides for my talk in PDF format for anyone interested.

At yesterday’s Chicago Python User Group (ChiPy) meeting, I gave an informal presentation on PyPy, a project that I’ve been interested in lately. I’ve posted the slides here as a PDF.

Be warned, though, that PyPy is by no means my area of expertise, so these slides may not be terribly accurate. I’ll be fixing them as I learn about their errors.

In late 2005, three colleagues and I founded a company called Humanized. A little over a month ago, we released our first two products, Enso Launcher and Enso Words.

I’m indebted to my incredible co-workers, Jono DiCarlo, Aza Raskin, and Andrew Wilson, for making this possible. Working at Humanized has certainly been the best job I’ve ever had, not to mention an excellent learning experience. Naz Hamid was also instrumental in providing us with superb graphic design and was very helpful as a business mentor in general. Special thanks also go to Andrew Huff, Sten Larsson, Erik Christensen, and Megan Bernard.

If you’d like to learn more about our product line, you may want to take a look at the Enso tour movie.

Back in 2005, while I was taking a class taught by the late Jef Raskin at the University of Chicago, I was inspired by his program The Humane Environment to write some Emacs commands that would make software development a little easier for myself. Based on some interest from the Chicago Python User Group, I’ve polished the code a bit and published it here.

Read more about pymdev, A Python Emacs Development Module.

The following is a summary of stuff I worked on before the new Toolness was created, but after I stopped maintaining any of my old sites.

Programming

Narrowcaster – During the summer of 2004, I realized how great RSS syndication was and decided to get an aggregator. Unfortunately, all of them were horribly complicated: highly modal interfaces, tons of tabs and controls and buttons to mess around with and what have you. Taking some inspiration from the design of Google News, I whipped up my own aggregator using Python and MySQL. The interface is relatively humane, and the aggregator features some built-in filtering of certain feeds: for instance, stories from Slashdot that I’m not interested in–e.g., anything under their “Linux” category–are automatically filtered out. Since this was created solely for personal use, it’s still rather buggy in some rarely-used places; nonetheless, one year later, I (and at least one other person I know) still use this aggregator multiple times per day. The name “narrowcaster” refers to the concept of narrowcasting, which I first encountered in Nicholas Negroponte’s book Being Digital.

SWKOTOR2 Secret Tomb Bugfix – In June 2005, I played through Star Wars – Knights of the Old Republic II: The Sith Lords, which ended up being a terrific game. However, there were also a number of major scripting-related bugs in the game, a few of which tripped me up while I was playing it. After finding out about some of the restoration projects going on to fix the game’s bugs and restore some of its cut content, I decided to contribute.

Writing

A Farewell to Jef Raskin – This is something I wrote in remembrance of the death of Jef Raskin, commonly credited as the inventor of the Macintosh computer, in February 2005. Jef was a professor of mine in graduate school and later became my employer.

Plundered Hearts review – During the spring of 2004, I played through a slew of old Infocom interactive fiction titles and wrote reviews for three of them. The other two were for Planetfall and Wishbringer.

Food Force review – Food Force was a ridiculous little edutainment game that the UN World Food Programme released in the spring of 2005. Having a particular interest in the oft-neglected genres of video gaming–especially edutainment–I decided to review this title.

Façade progressive review, prologue – This is the beginning of my first progressive review for The Game Chair, of the interactive drama Façade. Also see parts one and two.