Monday, December 29, 2003
PyObjC fun

I can't keep Python away. Even when I'm busy writing code that I think will stay in C or ObjC land, Python creeps in.

In service to my obsession with 1D cellular automata, I've been writing a lot of C code. And it's been working quite well -- the nature of CA calculations means that I do not run up against the difficult bits of C much. I get to use it in the sweet spot, and I find myself rediscovering an appreciation for it. I find myself appreciating it's simplicity and speed. One of the pleasures of Python is simplicity, a simplicity in doing some difficult things. But you pay for that simplicity with speed.

Even the memory management stuff is not a pain. It's obvious where the memory needs to be allocated, and it's obvious where it needs to be freed.

But where I start to miss Python is when I start to touch on the bits that interface with me. ObjC and Cocoa is fine for coming up with the majority of the user interface, but the particular domain that I'm playing in, cellular automata, tends to specify itself with equations, or at least in a manner that does not lend itself to user interface widgets. When you are looking at it, you want to just type in an expression and see the picture that the expresion represents.

Some would start getting excited by the challenge of writing an expression parser in C or ObjC, and maybe I'll do that in the future. But it's so much easier to write that kind of thing in Python, and the PyObjC bridge makes that so easy to do, it's somewhat silly not to use it.

I had this idea in my head -- I wanted to be able to type something like:

totalisticRule(20, k=2, r=2), randomSeed(100), lines(200)

and have it run the automata (creating an image similar to the image here, specifically the image in the lower right hand corner).

The solution was simpler than I had anticipated. I created a quick Python library that defined the totalisticRule, randomSeed, and lines functions to take their arguments and use PyObjC to call back into the program and set the appropriate parameters. Then, I defined a Python class with a method called by the main program to parse the inputs. The parsing is easy, I just pass the string to eval(), and Python does all the hard work of parsing the string, and then calling the functions. Extending the expressions available is a simple matter of just defining more Python functions within the library. After calling eval(), I then call back into the main program and cause it to render the automata.

Eventually I would like to explore the idea of creating a kind of worksheet interface, similar to the Mathematica notebook concept. I've also given some thought of packaging up the C-code CA engine as a Python extension, and doing the rendering with PIL, which might make it much easier to do the worksheet thing.

Some would question the idea of slapping something akin to a command line interface onto a GUI program, and I would make the observation that it's the classic coder move -- making an interface only another coder would love. But hey, it was a fun way to explore the possible. Sometimes you get an idea in your head, and you are just not satisfied until the idea gets expressed.

9:37:36 AM    comments ()  trackback []