Speak and Shout

Raven Checkers released

noreply@blogger.com (Brandon Corfman) — Tue, 28 Oct 2008 21:15:00 +0000

I published my first public version (0.3) of Raven Checkers to Google Code a few weeks ago. It has been a fun adventure to develop a cross-platform checkers game engine and GUI in Python.

Some interesting items about Raven from a development standpoint:

One or two player mode, plus an "autoplay" feature that pits the AI engine against itself.
Cross-platform Tkinter GUI with model-view-controller (MVC) architecture.
Undo and redo move feature.
AI opponent uses a standard alpha-beta search algorithm which runs in a background process (using the 2.6 multiprocessing library) with a customizable "think time".
Board Setup allows you to configure the pieces on the checkerboard, set the number of players, and select which player goes next.
Flip Board allows you to rotate the board 180 degrees to view pieces from either Black or White's perspective.

As I've mentioned in a previous post, my success in developing Raven owes a lot to Martin Fierz and Peter Norvig, who developed the evaluation function and search code that are used inside the game. Thanks to both of you for making your code open-source so that others could learn from and build on it.

My future plans for Raven involve taking it in a different direction than a typical game engine. Most checkers or chess programs go the route of deep search combined with perfect opening and endgame databases. These techniques are well-explored and not really all that interesting to me. I plan on making a big change in future versions of Raven by relying more on planning than brute-force search. Since Python is not a high performance language, it's encouragement to make Raven work smarter, not harder.

Here's my to-do list so far:

Implement a hierarchical task network (HTN) planner that will devise opening themes and endgame strategies. These plans will be based on tactics and endings from Richard Pask's books Starting Out in Checkers and Play Better Checkers & Draughts, which I use in my own checkers study. The architecture of the planner will be very similar to the one used for Bridge Baron, featured in Chapter 23 of the book Automated Planning.
Add a transposition table and some move ordering to help with alpha-beta search depth. (I will probably make use of the transposition table code in PyChess or Chesstools.) Despite my preference for using the planner, I would like to be able to fall back on good search for the early- and late-midgame when play becomes a bit more muddled.
Add a save/load game feature, along with some way of annotating different moves in the game. (My thoughts on the "annotation" feature are a little fuzzy, but it's something I want for checkers study.)
Make the undo and redo work correctly with the background AI processing. Right now, Raven doesn't stop its search if an undo/redo is executed, and it should.
Create some official distributions so a user doesn't have to checkout the code themselves or require Python to be installed on their system. (Although listed last, this is really something I will likely tackle first, so more folks can enjoy Raven.)

There is plenty here, but I'm not in a hurry. This is just a fun side project. I have the vague idea that I'd like to get most of the features above (certainly the planner and its knowledge base) implemented within a year, so I could give a presentation at PyCon 2010. Seems like a good goal to keep in view.

A checkers game

noreply@blogger.com (Brandon Corfman) — Tue, 20 May 2008 16:08:00 +0000

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:

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.
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.
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.

Movie blog

noreply@blogger.com (Brandon Corfman) — Tue, 20 May 2008 12:30:00 +0000

From the number of subscribers at Bloglines, it doesn't look like too many people know that Roger Ebert has a blog. His latest post is about the new Indiana Jones movie, which sounds like it's worth seeing.

kNose 1.1.1 released

noreply@blogger.com (Brandon Corfman) — Tue, 01 Apr 2008 16:00:00 +0000

This release of kNose updates the extension to work with Komodo 4.3 and nose 0.10.1.

It also fixes a problem with the interaction of certain directory paths when running nosetests. Also, I include a message and tooltip for when kNose can't find any unit tests in your project. The tooltip specifies the environment variables and arguments passed to the subprocess module, so it should be easier to debug specific problems with any user's system.

For those who don't know, kNose is a Python unit testing extension for Komodo Edit. It is a GUI frontend for the excellent nose framework written by Jason Pellerin.

Happenings at PyCon

noreply@blogger.com (Brandon Corfman) — Thu, 13 Mar 2008 22:55:00 +0000

My friend Steven is busy preparing for his Django talk at this year's PyCon. In his spare time, he's also taking shots of the conference and twittering his experiences. He shares:

The geek thing this year is the eeepc -- I've seen at least 5 or 6 already tonight.

I was unable to attend the conference, but I'm monitoring Planet Python to keep track of the goings-on. Maybe next year!

The Impatient Developer's Guide to Nose Plugins

noreply@blogger.com (Brandon Corfman) — Mon, 25 Feb 2008 23:38:00 +0000

Eric Promislow of ActiveState has been working with the nose unit-testing framework in order to hook it into the new version of Komodo IDE. Along the way he figured out how to write a nose plugin, and he's documented his work in this article. (Poor Eric misspelled my name as Brendan, but otherwise it's a great article! ;D )

I'm working hard right now on a game, but this information is cool enough that I could be persuaded to update kNose to use a nose plugin like Eric describes. However, Komodo 4.3 could very well obsolete my work. Are there enough kNose users out there that would like to see an update, or would you rather wait for the next version of Komodo and its unit testing support?

Pygame bookmark rollup

noreply@blogger.com (Brandon Corfman) — Wed, 16 Jan 2008 17:11:00 +0000

I've found a bunch of Pygame-related bookmarks lately that I thought I'd post. These don't seem to be all widely linked, so maybe they'll be useful for other Python game programmers out there.

Chapters 5 (Making Things Move) and 7 (Take Me To Your Leader) of Will McGugan's Beginning Game Development with Python and Pygame. Personally, I find chapter 5 to be the most valuable of Will's book.
pyMunk, a wrapper around the Chipmunk 2D gaming physics library.
A couple versions of Pygame main loops: Simon Wittber's mainloop and Hectigo's Splush.
Pygsear, a higher-level Pygame framework that takes care of much of the lower level setup of sprites and events and objects.
Pygame Extended and Rabbyt, both 2D sprite library add-ons to Pygame that use OpenGL acceleration.
Python Game Kit, plenty of .egg files that contain useful Pygame utilities and addons.

Something I hate about Python's re module

noreply@blogger.com (Brandon Corfman) — Tue, 18 Dec 2007 19:02:00 +0000

UPDATE: I've gotten a couple comments about this, and both seem to illustrate (with varying degrees of tact) that my complaint wasn't all that clear. My problem with the re module is this: Python's documentation for the re.match function is match(pattern, string, [flags]) where pattern can be either a regex string or a compiled regex object. If it's a compiled regex object, then supplying an optional flag to re.match (in my case, re.IGNORECASE) doesn't work and, more to the point, fails silently. I think this should throw an exception if it's not going to work. However, I really think that it should work the way I've illustrated, because, IMO, it's the most natural way to use the API.

----
I've been burned at least three separate times by the following problem: I'll start out with a simple uncompiled regex for testing and then switch over to a compiled regex. Suddenly, the whole thing stops working.

Here's an example of what I'm doing below. (Example taken from O'Reilly's Regular Expression Pocket Reference by Tony Stubblebine.)

import re
dailybugle = r'Spider-Man Menaces City!'
pattern = r'spider[- ]?man.'
if re.match(pattern, dailybugle, re.IGNORECASE):
print dailybugle

This prints out 'Spider-Man Menaces City!' as expected. So now I want to compile the regular expression now for speed. I change the code to look like this:

import re
dailybugle = r'Spider-Man Menaces City!'
pattern = re.compile(r'spider[- ]?man.')
if re.match(pattern, dailybugle, re.IGNORECASE):
print dailybugle

Looks simple, right? I just surrounded the pattern string with a call to re.compile(). Unfortunately, the whole thing now quietly fails. What the ... ? Take the re.compile out, it starts working again.

The solution is to move the re.IGNORECASE flag into the re.compile call, like so:

import re
dailybugle = r'Spider-Man Menaces City!'
pattern = re.compile(r'spider[- ]?man.', re.IGNORECASE)
if re.match(pattern, dailybugle):
print dailybugle

In my opinion, this solution is very unintuitive and requires more rejiggering of the code than it should. But even worse is that in my first attempt to use a compiled regex, re.match can receive a re.IGNORECASE flag that it subsequently disregards. This type of call should throw an exception, in my opinion.

Anyone know a reason for this bad (and seemingly buggy) behavior?

Phil Hassey's Galcon featured on AIGameDev

noreply@blogger.com (Brandon Corfman) — Mon, 26 Nov 2007 20:46:00 +0000

UPDATE: There's a second interview article with Phil that's just been posted.

AIGameDev just posted an article on Galcon's AI framework. (In case you haven't heard, Galcon is an "awesome high-paced multi-player galactic action-strategy game. You send swarms of ships from planet to planet to take over the galaxy.") Galcon is also written in Python and Pygame, and it's nice to see both the language and its great gaming library get some more press.

Garbage can samurai

noreply@blogger.com (Brandon Corfman) — Thu, 01 Nov 2007 16:17:00 +0000

A guy who made a full suit of costume armor from a Rubbermaid 32 gal. trash can.

Via Larry Hollis.

doctest with Python

noreply@blogger.com (Brandon Corfman) — Tue, 30 Oct 2007 15:53:00 +0000

At home I'm translating some C++ code to Python for doing 3-D math with vectors and matrices. (Yes, I know about NumPy -- I have my reasons.) Matrix math requires care to get all the indices right, and it's a good application for writing tests to make sure I've done things correctly.

About the same time as I started this project, I saw the following response from Fredrik Lundh (effbot) to a comment on Reddit:

>what was I thinking using self.assertEqual() in Python?!
Yeah, what were you thinking? Here's how it's spelled in Python, when using the One True Testing Tool (wink):
>>> foo.bar
3
(where all you actually typed was foo.bar; the rest is just good old cut and paste).

Of course, Fredrik here is referring to the doctest module. I'd seen Peter Norvig use it before in some of his Python code, and I should've paid attention then. Fredrik's comment gave me the push to finally try it. I found that it fits my style of Python coding very naturally, since I typically shake down my code at the REPL as I go. I cut and paste my interactions at the prompt into my class, and I've got some tests up and running quickly. The nice thing is that I'm helping to document my code (inline) as I go, which is a second advantage of doctest. I've never been that enamored with writing a separate test class like I've tried with the unittest library, for instance.

Good stuff. Thanks, Fredrik.

Linux Mint Cassandra

noreply@blogger.com (Brandon Corfman) — Thu, 18 Oct 2007 15:40:00 +0000

I bought a new 160GB hard drive from Wal-Mart with a gift card I received for my birthday (Thanks, Dad!), and I decided to install Mint on it. For those that may not have heard of this particular Linux distribution, it is built on top of Ubuntu. The benefit is that it also includes all of the codecs that you would need to hunt for around the web to get your audio/video/movies to play correctly.

I was expecting to have to do some weird tricks with my hardware setup since I still wanted to be able to boot into Windows. I have two 80 GB Serial ATA hard drives that are hooked into a Adaptec RAID card in a mirrored configuration. I wanted to keep this setup, and this necessitated a separated HD for Linux -- I didn't want to do partitioning, and I've had bad luck with separate partitions getting corrupted anyway.

Since the Windows hard drives boot off the Serial ATA card and my new Linux HD was a standard EIDE, I was happy to find that the Mint boot loader actually figured out my weird setup. The loader simply intercepts the boot process and offers me a menu on which operating system to choose when I start up. I was a little wary of picking the Windows option the first time, but it worked just fine.

Mint itself is terrific. The only hitch I had was that my Sound Blaster Audigy wouldn't work without disabling the onboard audio in the BIOS. No loss since I never use the onboard audio anyway. Last night I was coding in Python with PIDA, listening to my music with Amarok, and watching Rear Window (and Grace Kelly!) on DVD with Totem Movie Player.

Everything works together smoothly. I'm impressed.

Skeptical Christian

noreply@blogger.com (Brandon Corfman) — Thu, 18 Oct 2007 15:36:00 +0000

I've been meaning to post for a while about Kyle Deming's Skeptical Christian website. He's done current book reviews on Richard Dawkins' The God Delusion and Daniel Dennett's Breaking the Spell: Religion as a Natural Phenomenon. He also tackles philosophical viewpoints such as the Cosmological Argument. Also, one of the best things about his site too is his (somewhat irregular) podcast in which he responds to questions posed by his blog readers. Highly recommended.

kNose 1.1 released

noreply@blogger.com (Brandon Corfman) — Tue, 14 Aug 2007 03:02:00 +0000

kNose is a Python unit testing extension for Komodo IDE/Edit. It is a GUI frontend for the excellent nose framework written by Jason Pellerin.

This release of kNose fixes several bugs with parsing nose output, and I hope it solves all the problems that have been reported. Thanks to Christoph Zwerschke and Arnar Birgisson for their help with testing, use cases and patch submissions.

Version 1.1:

Added -v option when calling out to nose so that verbose output is returned in all cases, and parsing works correctly.
Scan URIs for the word 'test' before they are passed to nose to increase speed and avoid additional confusion in parsing.
Changed parsing for test names to use regular expressions for speed and more robust behavior.
Improved parsing to handle classes derived from unittest.TestCase correctly.

You can download it here.

kNose 1.0 released

noreply@blogger.com (Brandon Corfman) — Thu, 19 Jul 2007 15:46:00 +0000

kNose is a free Komodo IDE/Edit extension for Python unit testing; it uses the nose unit testing framework written by Jason Pellerin.

kNose is available for download here, along with documentation I've provided on how to install and use it.

Hope you enjoy it!

A quick kNose update

noreply@blogger.com (Brandon Corfman) — Thu, 05 Jul 2007 01:07:00 +0000

Sorry, I promised to keep everyone updated, and I haven't been doing that.

I've finished working on expanding and collapsing the tree view and running tests in a background thread. I'm currently writing the code to display tooltips in the tree for any tests that had failures/errors. It's been hard to find out how to do this, because it's very hard to google for "tooltip treeview XUL" (and other combinations thereof) and get any meaningful results. However, I finally found some sample code to look at, and I'm hoping this doesn't take me very long.

I've noticed some small bugs in my parsing of nose's output results, and I also need to save some of the treeview settings inside of Komodo's preferences. Both of these "to do" items, however, are fairly insignificant.

My plan is to release it by the end of this week.

kNose extension under development

noreply@blogger.com (Brandon Corfman) — Mon, 11 Jun 2007 15:47:00 +0000

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:

make the tree nodes expandable and collapsible,
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.)
run nose in a background thread so that it doesn't freeze up Komodo while the tests are running.
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!

noreply@blogger.com (Brandon Corfman) — Sat, 19 May 2007 01:17:00 +0000

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.

More on VMWare

noreply@blogger.com (Brandon Corfman) — Fri, 23 Mar 2007 01:09:00 +0000

I tried VMWare Server under my WinXP machine after the comments on my previous post. Tonight I'm going back to Player instead. Despite Player's few annoyances, Server has more: several new services run in the background, and I notice the slowdown during boot time and while I'm playing games that require the full use of the CPU.

That is all. :)

Ubuntu install

noreply@blogger.com (Brandon Corfman) — Tue, 13 Mar 2007 02:12:00 +0000

Those who've been following my del.icio.us bookmarks know that I've been recently looking at laptops and desktops with Linux pre-installed. My interest in a new computer coincided with my old computer starting to fail. But wouldn't you know it! Turns out a new power supply and keyboard solved my problems, and I was still left with a serious case of Linux envy.

Once I got my computer running again, I decided to look at installing an Ubuntu image under VMPlayer for Windows XP. (This is the free virtualization software from VMWare that allows you to run one operating system under another one.) I was surprised how well it worked, although there were some issues that I had to look up on various newsgroups. Here's the process I used:

Download the latest Ubuntu 6.10 image.
Download and install the evaluation version of VMWare Workstation. (This includes VMPlayer plus VMTools, which you need for getting screen resolutions above 800x600.)
Run Workstation, start the Ubuntu image, and "install" the VMTools (located in Workstation's menu). Confusingly, this just drops a virtual VMTools DVD image on your Ubuntu desktop; you have to then open up the image and run its installer.

Now you can change your screen resolution to something higher, set VMPlayer to run full screen on startup (and unpin the annoying toolbar), and you're all set.

If you want, you can also uninstall the eval version of VMWare Workstation, and then download and install the smaller (and free) VMPlayer. Your image (with the VMTools install) will remain intact. This is also perfectly legal.

Having this image has satisfied my Ubuntu lust for the moment. I spent some time downloading lots of cool Python libraries using the Package Manager (even easier than using easy_install!). I'll still probably get a Linux friendly laptop at a later point, but Doris' VAIO is still chugging along, and it's hard to justify a new computer when we're still furnishing our basement.

Komodo Bonus Hack: Explore Project Directory

noreply@blogger.com (Brandon Corfman) — Sat, 10 Feb 2007 03:58:00 +0000

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

noreply@blogger.com (Brandon Corfman) — Sat, 10 Feb 2007 03:27:00 +0000

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

noreply@blogger.com (Brandon Corfman) — Fri, 09 Feb 2007 14:51:00 +0000

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:

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.
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.
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.
Change to your Python installation's scripts directory.
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:

Right-click on the Pylint macro in the toolbox and click Properties.
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?)
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

noreply@blogger.com (Brandon Corfman) — Thu, 08 Feb 2007 01:32:00 +0000

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

noreply@blogger.com (Brandon Corfman) — Wed, 07 Feb 2007 04:05:00 +0000

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!