I decided that grok could use some serious refactoring. So much refactoring, that I could probably get away with rewriting it faster than redesigning portions of it. Since I need to know Python better, and I am more familiar with OO in Python than I am in Perl, I figure I should rewrite grok in Python. Python already has one critical feature that I need in grok, named captures. The hack for this in perl is unwieldy and potentially unmaintainable if future perl versions change the format or deprecate it. It is listed in 'perldoc perlre' as experimental.
At any rate, I made a little prototype that tries to be very OO. My experience with Good(tm) object oriented programming is still limited. The CS curriculum at RIT sucked for teaching proper OO, too many professors taught wildly different styles or were unclear about what Good(tm) OOP should look like.
Therefore, rewriting grok is a good opportunity to explore test-driven development and maintainable object-orientation. Oh, and synergism too. *shifty eyes*
I've got a bit of code up and running already, and writing "for tests" seems to be a very cool way to think about programming. If I force myself to write easily-testable code, then writing tests is easy. Furthermore, initial experience seems to show that adding new features is much easier when all of the code is compartmentalized.
If nothing else, I wrote a somewhat cool debug method that accesses the call stack for function, class, module, etc. Check out the 'debuglib.py' file. The output looks something like this:
grok/groklib.py:52] RegexGenerator.saveRegex: happy message hereThe file, line number, class and function name are all discovered magically in debug(). I like this.
If you get bored, you can look at the original stuff here: scripts/grok-py-test