A checkers game

I've made a couple different attempts before to write a Checkers program in Python, but for various reasons, the project stalled. This time, I've been quietly working on it behind the scenes, and last night I played my moves against an intelligent computer player. Some reasons why I had success this time around:

1. Using existing open-source code as a reference. Before I was trying to do everything myself from scratch. Sometimes this can be useful for learning purposes, but in some cases it can just be an exceptionally bad use of time. Now I'm taking a look at code that other people have written and reusing it where I can. For instance, Martin Fierz's Simple Checkers has a good, basic evaluation function that I've been able to use, and Peter Norvig's elegant Python implementation of minimax would be hard to improve upon. There's enough other interesting challenges in trying to develop my program -- there's no need to waste time doing wheel reinvention.
   
2. Testing. This is the first time I've worked on a personal project where I felt unit testing while I developed was an absolute necessity. (Although I did test-after, not test-driven development. Sorry, agile folks.) I always do testing in the Python shell, but it's somewhat informal. This time it was formal. Checkers has a number of rules about moves/jumps that are important to get right, and almost every test I wrote uncovered a bug or a subtle problem with my data structures. Thumbs up for unit tests.
   
3. Focusing on the logic, not the GUI. Before I was developing my checkers GUI in tandem with the game model. Now I'm concentrating on getting the logic right first, and my initial "GUI" is simply an ASCII representation of the checkerboard. In the past, with too many pieces of code changing at the same time I was getting overwhelmed, especially when trying to refactor. Focusing on the GUI is seductive but is ultimately the wrong use of time early in the project.

In regards to #2 above, the focus on unit testing has also continued to drive the development of my Komodo extension, kNose, which is also very positive. I'm working on updating the extension to use nose 0.10.1 and its much improved support for plugins. (And in another major milestone, kNose is now hosted on google-code and has a new project member, Christoph Zwerschke, who's been a huge help.)

Once my Checkers game is released, I'd also like to donate it back to the AIMA project as an example of what can be done with community code.

kNose extension under development

For about a month, I've been quietly developing another Komodo Edit/IDE extension called kNose. It's a GUI front-end for the nose unit testing framework for Python written by Jason Pellerin. I wanted something that would make it easy for me to jump into testing as part of my normal development. Despite the cool nature of auto-discovery and execution of unit tests with nose, I'm still too lazy to use it if it's not integrated with my IDE.

Here's a screenshot of how things look so far for the curious:


Yes, that's a red bar to indicate that some of the tests didn't pass. The auto-test feature, when checked, will run the tests each time a file is saved in the editor. When auto-test is unchecked, then the Run Tests button will kick off the unit tests manually.

Basically, my remaining to-do list is as follows:

1. make the tree nodes expandable and collapsible,
2. handle error reporting properly (whatever that means I haven't decided ... hover over a node to see a tooltip? ... double-click to get a dialog with the error message? I'll probably try both and see which style I like.)
3. run nose in a background thread so that it doesn't freeze up Komodo while the tests are running.
   
4. test on both Linux and Windows to see that things check out. (I'll be looking for a volunteer with a Mac as I get closer to release.)
   

The last, detail stages of the project always seem to be the hardest, so I'm posting to encourage myself to "press on toward the goal". Also, I was curious if other Pythonistas in the testing community would be interested in my extension.

It will probably be another two to three weeks before I finish since this is definitely a part-time project. I'll keep everyone posted.

I won a $150 prize!

I entered the Komodo Extensibility Challenge, and got a prize for 2nd runner-up with my "Find in Project Files" extension. Honestly, I didn't really expect to win, but I wrote an extension that was useful to me, and I guess others found it helpful too. Cool. I'm going to get a pair of K2 Radical 100 inline skates with my Amazon gift certificate, although the $150 prize only gets me halfway there. Still, I haven't had a nice pair of skates that fit me in a long while, and I'm looking forward to skating the B&A trail again in style.

Komodo Bonus Hack: Explore Project Directory

Alright, one more hack ... this is so simple it may not be worth mentioning, but I find it really useful. It's also not Python specific.

I've written a quick Run Command that brings up Windows Explorer located inside your current project directory. Besides giving you a quick access to file operations on your project, it's also convenient for Komodo Edit users that use TortoiseSVN (or similar tools) for source-control purposes.

If you're a Unix GNOME user, you're not out of luck: you can change the Run Command to use "nautilus" instead of "explorer", for similar results.

You can download the Explore Project Directory file here.

Komodo Hacks: Improving Python Help in Windows

This last hack for the week beefs up the context-sensitive help for Python in Komodo. By default, the Shift-F1 help in Komodo does a Google site search on docs.python.org for the current word under the cursor. I prefer instead to use the HTMLHelp manual that comes with my standard Python installation since it's often much faster and efficient than a web search.

You can download my Python Help macro here. It brings up your local Python reference with an HTMLHelp API call, with the current word under the cursor placed in the Index tab. Simple but effective.

Notes:

• This Help macro remaps the F1 key to bring up the Python manual instead of bringing up Komodo's internal help, since I use language help much more than IDE help. You can always change this in the macro Properties if you're used to Shift-F1 instead.
• You should also check the macro code to make sure that the local of my Python installation (c:\python24) matches yours, or you'll need to change it.
  

I've got more ideas percolating but they'll have to wait until another week! Hope these hacks make your work with Komodo and Python more enjoyable.

Komodo Hacks: Integrating Pylint

UPDATE: Todd left a comment on how he didn't like Pylint's verbosity. You can add a -e option to the command line to show errors only instead of stylistic warnings.

UPDATE: I see this hack has already been covered by John and Mateusz.

I'm not enjoying today's hack as much as I'd like. Pylint is great, but getting it installed and configured is much more painful than it should be. For one thing, Logilab has configured a .egg file for Pylint so that you can ostensibly use easy_install to get it on your system -- but the .egg doesn't load any of the other dependencies that are needed. Very frustrating. Consequently, we'll go about the install process manually. I'm writing the steps below from a Windows perspective, but I've tried to note where a Unix install is slightly different.

How to get PyLint installed and configured for Komodo:

1. Download Pylint and the Pylint dependency modules from Logilab's site: logilab-common and logilab-astng. The download links are in the upper-left corner of the page.
2. Extract all the packages from step 1, preserving the folder structure. WinZip is the best for this on a Windows system; if you have a Unix-based OS, you can use gunzip -c [MODULE].tar.gz | tar -xf - or similar.
3. Open up a command prompt, make sure your Python executable can be found in your PATH, and type python setup.py install inside the extracted common, astng, and pylint directories in turn.
4. Change to your Python installation's scripts directory.
5. Type pylint --generate-rcfile > standard.rc at the command prompt to create a Pylint configuration file. (If you're using a Unix system, you'll need to prefix the pylint command with a ./ )

Now you're ready to download Run Pylint macro here. Install it into Komodo by using the Import Package option under the Toolbox menu.

Additional configuration is needed to set up the macro for your system:

1. Right-click on the Pylint macro in the toolbox and click Properties.
2. Change the path to pylint in the Command text box to match the location of your python installation's scripts directory. Also, if you're using a Unix system, you'll probably need to remove the quotes around the %F in the text box as well. (Can someone verify this for me?)
   
3. Change both the directory paths in the Environment Settings list to match the location of your Python installation as well.
   

Usage notes:

• Double-clicking on the Pylint macro in the toolbox will run pylint on the currently viewed file and print a report in the Command Output tab. Each line in the report can be double-clicked, and Komodo will jump to the matching line in the file.
• The standard.rc file that was generated in step 5 above can be edited to customize the types of errors/warnings that Pylint will generate. The .rc file is commented thoroughly so you should be able to figure out what's going on with a little study and experimentation. As an alternative, pylint can also be customized with command-line parameters; type pylint (by itself) at a command prompt to see all the different possibilities.

Tomorrow's hack: beefing up context-sensitive help for Python under Windows.

Komodo Hacks: Rename Occurrences

This Komodo hack allows you to rename all occurrences of a variable or method name wherever it appears in your code. This is the last of my macros this week that uses Bicycle Repair Man; if you missed my previous post on how to get the BRM package into Komodo, it can be found here.

You can download the macro here. Install it into Komodo by using the Import Package option under the Toolbox menu.

Usage notes:

• Highlight a variable or method in your code and double-click on the Rename macro in the toolbox. The macro will prompt you for the new variable or method name and then perform the rename operation.
• Before refactoring, Komodo will prompt you to save your file if necessary. (This is a requirement of BRM.)
• After refactoring, Komodo will tell you that your file or files have changed and prompt you to reload them. Go ahead! You should see your changes in the updated file(s). If you don't like what you see, you can Undo the changes, via the Edit menu or CTRL-Z.
• Rename Occurrences may not always work like you expect. As an example, you'll want to rename method names where they are originally defined; otherwise, the renaming will only be local and not propagate throughout your code.
  

Tomorrow's hack: integrating PyLint into Komodo.

Komodo Hacks: Extract Method

Today's hack allows you to highlight a section of existing Python code in Komodo and refactor it into its own separate method.

Like yesterday's hack, Extract Method uses Bicycle Repair Man for its functionality. If you didn't catch the procedure for including the BRM package into Komodo, see my last post.

You can download the macro here. Install it into Komodo by using the Import Package option under the Toolbox menu.

Usage notes:

• Just highlight a section of code, and double-click on the Extract Method macro in the toolbox. The macro will prompt you for the name of the new method and then perform the refactoring operation.
  
• Before refactoring, Komodo will prompt you to save your file if necessary. (This is a requirement of BRM.)
• After refactoring, Komodo will tell you that your file has changed and prompt you to reload it. Go ahead! You should see your changes in the updated file. If you don't like what you see, you can Undo the changes, via the Edit menu or CTRL-Z.
  

One more BRM macro to go, coming tomorrow!

Komodo Hacks: Find References

UPDATE: Trent Mick posted a simpler method for getting the BRM package into Komodo. I've modified my original procedure below to include his suggestion.

Komodo is my favorite Python IDE. Since ActiveState has recently released their new Komodo 4.0, I've decided to publish a full week of Komodo Toolbox commands and macros that should prove useful for Python developers. (Note that I'm primarily a Windows user, but most of these commands/macros will be able to be used on other platforms as well with little or no modification.)

I'm starting off the hacks with a "Find References" macro that compliments the new "Go To Definition" feature in the latest Komodo. The idea is to be able to highlight a variable or method in your Python code and then double-click Find References in the toolbox to see all uses of that variable/method throughout your code.

I use the Bicycle Repair Man (BRM) refactoring tool, written by Phil Dawes, to implement this macro. That means the first order of business is to install BRM into Komodo's Python directory so that the module can be called from within a macro.

How to install Bicycle Repair Man into Komodo:

1. Download the BRM nightly build. I used the bicyclerepair-nightly.tar.gz.tmp file dated October 9, 2006. Rename this file to bicyclerepair-nightly.tar. (I know it looks like a gzipped file, but trust me, it's really a TAR file.)
   
2. Extract the build into a convenient directory. WinZip is one of the easiest Windows tools to do this. On a Unix platform, you can use tar xvf bicyclerepair-nightly.tar
3. Put a "bike.pth" text file in [komodo-install-dir]/lib/mozilla/python. This file should contain the path to the bicyclerepair source directory. For example, if you had extracted the bicyclerepair folder to the root of your C: drive, your "bike.pth" would contain the single line "c:\bicyclerepair". (Again, I'm sure the Unix users can figure out how this would look on their system.)
   
4. Re-start Komodo for it to pick up on the new .pth file.
   

Now you're ready to load the Find References macro into your Komodo IDE or Komodo Edit 4.0. Use the Import Package option under the Toolbox menu to load the findreferences.kpz file into Komodo.

The usage is pretty simple: highlight a variable or method in your code and then double-click the Find References entry in the Toolbox. The macro will scan your code for a second or two (or longer depending on the length of your code and the number of imports) and then output the results in the Command Output tab. You can then double-click on any line in the output to jump to the corresponding location in the code.

A few items of note:

• Find References may not work like you expect in certain cases; for example, when finding references for a class instance variable like 'self.foo', just highlight 'foo' - don't include the 'self.' prefix.
  
• Due to a limitation of Komodo's Python macros, Find References has to use a 'helper' Run Command to populate the Command Output tab. I placed this Run Command inside a separate 'Helper Commands' folder to keep it out of the way; make sure you don't change it or delete it by mistake.
  

Thanks to Shane Caraveo, Trent Mick, and Jeff Griffiths of ActiveState for helping me out with these hacks. Stay tuned for more Komodo posts through the rest of the week!