Lonely Lion

Hot on the heels of yesterday’s HOP reading, I was thinking about how to implement a dispatch table in Python. For a little while I thought it would be awkward at best, without all the fancy references that Perl relies on. As an experiment, I opened up an interpreter and ran:


In [1]: def sum(num1, num2):
...: return num1 + num2
...:

In [5]: i[0](1,1)
Out[5]: 2
</function>

Yikes. That was easy. I’ve done a sort of dispatch table with compiled regex’s in Python, but I’ve never tried putting a function in there. I’m not sure why I doubted it would work.

I wrote a little email parser for my improv team yesterday. It updates our rehearsal schedule based on the email subject line. So something like, “chris 9/27 out” removes me from the list of people attending that rehearsal. “chris 9/27 in” puts me back in. It’s a goof robot that I’m hoping fixes a scheduling problem we’ve had for a while now. The line is parsed, broken up, and then sent through a gauntlet of if – thens until it finally arrives at the command that needs to be run.

At the time, I knew I was probably doing this in a not robust way, but I forged ahead, wanting to just get it done. The dispatch table concept is going to make it a lot easier to add commands to the robot without much fuss. Neat.

SCTHUMBZZZ.jpg” alt=”Higher-Order Perl: Transforming Programs with Programs” />

I started reading Higher Order Perl again this morning. I forgot how versatile Perl can be, and how easy it is to write poor code. Chapter one, on recursion and writing functions that allow for reentry, made me want to re-do two projects I recently finished at work. Sadly, I fell for the trap of using a big list of global variables in both projects. I really should have written them a bit more functionally. I guess it’s good though, as it gives me a potential target for future refactoring.

Chapter two, on dispatch tables, fired off a bunch of ideas for a future someday / maybe sort of project that I have on a back burner. I’m desperate to write a domain specific language for something. Dispatch tables, and HOP’s specific examples to illustrate them, fit into that idea pretty well.

So, all in all, in about 45 minutes of train reading, HOP proved to be a great read.

I finished my first Myghty application over the weekend. The site is for my wife and her coworkers to sell hand-made jewelry. They’ve been making stuff for a while, and recently decided to step up production a bit. Camri designed the site, and I implemented it using Myghty and SQLObject. The address is http://www.uniqfindings.com.

I was pretty pleased with Myghty as a framework for web building. I used the autohandler and dhandlers with some good success, but didn’t use some of fancier “superset of Mason” features. The UF ladies have started to build a list of new features they’d like to see, which may lend themselves to some more Myghty goodies.

In the mean time, check out the site. The graphics are pretty fat, and need to be optimized a bit to speed up load times. We were pretty greedy when we were putting it together, sacrificing speed for pretty.

The topic of last night’s ChiPy meeting was “interoperability”. John Hunter showed us how to wrap stuff with Python, Brian Ray wrapped Python with stuff, and Michael Tobis clued us in to a bunch of acronyms. It was a good meeting. All three presenters said they’ll be putting their notes online.

In an effort to cull the number of side projects I maintain, I requested formal mailing list hosting from python.org for the chipy list. They set us up very quickly, and everything looks to be in place. So now, we’re chicago@python.org (very cool). If you’d like to sign up on the new list, the info page is here:

http://mail.python.org/mailman/listinfo/chicago

We’re still at http://chipy.org but may be requesting a python.org subdomain at some point in the near future. We’ve discussed it, and it seems doable, so it’s just a matter of me moving the chipy.org stuff to it’s new home, and getting in touch with the python.org folks.