Home > Python, TurboGears > Guido experimenting with generic functions, TG using them

Guido experimenting with generic functions, TG using them

April 10th, 2006

Guido has blogged about a generic function implementation (he uses the term Dynamic Function Overloading) that he has checked into the Python sandbox. It is good news to see work on this going into the core of Python. TurboGears 0.9 makes heavy use of Phillip Eby’s RuleDispatch package and it gives a lot of power in choosing an error handler, choosing an output format and even determining if a user is authorized for a resource, if you use a new package created by Alberto. We’re using it quite a bit behind the scenes and strategically exposing it here and there. If this becomes a standard part of Python, we don’t have to worry about people not understanding how the implementation works. Most excellent.

Update: in the comments, Bob Ippolito points out that Guido’s code is just doing dispatch by type and not by expression, as RuleDispatch does. I had noticed this originally, but tuned it out when I was posting. RuleDispatch is exceedingly powerful because of the way it handles expressions. What Guido describes is certainly a useful addition to Python and give people a chance to get used to functions being chosen at runtime, which will lessen the barriers to folks using RuleDispatch.

Python, TurboGears

  1. April 10th, 2006 at 16:59 | #1

    Guido is playing with dispatching functions by *type*, not nearly as useful as by expression.

  2. April 10th, 2006 at 17:05 | #2

    Good point. It will still help people to get used to the idea, but you’re right that it’s not the same thing.

  3. April 10th, 2006 at 18:28 | #3

    Yes; it’s definitely more limited than RuleDispatch, but it introduces a pattern that RuleDispatch also fulfills, just in a more general/powerful way. Proposing RuleDispatch itself would have been too radical I think, and too far from adaptation to make it a clear alternative to adaptation. People — including Guido — have used a process of implementation and reimplementation on the py3k list, until they felt comfortable with the result; RuleDispatch’s implementation is also too involved for that adoption process to work. But anyway, even if it isn’t RuleDispatch going in, it’s still going to make it much easier to justify and explain RuleDispatch’s role.

  1. No trackbacks yet.