Saturday, December 24, 2005

RuleDispatch on the move

It seems like those wily TurboGears folks are at it again, talking about actually using stuff I wrote (RuleDispatch, in this case). What is it with them, anyway? :) Whatever it is, I hope they keep it up. In all fairness, Django actually started using setuptools before TurboGears did, but nobody uses as many eggs for as many projects as TurboGears does, with over 75,000 eggs served and counting. And, from an IRC log I stumbled across this evening, it sounds like the Django developers recently considered using RuleDispatch too, although it also sounds like they decided not to bring in the extra dependency.

Maybe I'm biased, but I think you should just bite the bullet, guys; TurboGears depends on nearly a dozen eggs in order to install, but that hasn't stopped them from getting thousands of downloads. (The fact that everything but the bootstrap script gets downloaded automatically helps.) Plus, think of all those TurboGears users who now already have RuleDispatch installed, and could now "easy_install Django" to try your framework too, if you only added a download link to your PyPI project page!

But that's okay, you can wait to try RuleDispatch later. :) I've started some work on refactoring it so it can actually generate Python bytecode for generic functions on the fly, which basically means that it will end up being able to run at least as fast as hand-written Python in the limit case, and might make it possible to use Psyco (or some future PyPy JIT) to do further optimization. This is part of a general refactoring to separate the policy aspects of generic functions (i.e. what rules are in a given function and how should they be combined) from the dispatch implementation aspects (indexing, tree building, and actual execution).

There may be some minor API shakeups from all this, but probably not much. Mainly it should just make it possible to choose alternative implementations for a generic function's execution, independently of its method combination strategy and any other special features. This should be particularly useful for creating incrementally-updated generic functions, which would be useful for doing stuff like what PyDispatcher does, or for content-based routing engines, enterprise messaging systems, and all that sort of thing. Mainly, though, it should just simplify some of the existing code, get rid of some cruft, and (I'm hoping) be faster than the current engine at call time, using less C code.

It's all just a part of keeping up with the reputation I seem to be getting lately. In that IRC log I mentioned, after all, I saw this amusing comment:
rjwittams: I think eventually 'Eby' will be an adjective that means 'fucking cool, but insane'. 'That is a really eby trick!'
So, I guess I'd better head back to my magic workshop and get with the Eby-ing already. :)