Ian Bicking: the old part of his blog

Re: First Try at Generic Functions

"""I ended up just uninstalling that, though there's probably a better way to do it."""

If you install both of 'em as --multi-version eggs, you'll be fine as long as you never need both in the same program.

"""So if you wnat to change the representation of an object, but only in the context of one controller in your web app, then that doesn't fit into this system."""

You're probably aware of this, but you could always add a context argument with a None default value.

"""Dynamically scoped variables would probably address this case."""

Yep, and I do plan to add support for that to RuleDispatch as soon as I figure out whether my context variables proposal (work in progress) is likely to pass PEPping for stdlib inclusion in 2.5. Python needs (IMO) a standard way to handle task-specific context variables that can be used with lightweight threads, in place of the thread-local mechanism currenly used by e.g. the Decimal arithmetic context. Whether it's accepted or not, I'll be writing the library, and making it so generic functions can use it without constant-folding away the variables. (Currently, any subexpression that doesn't involve a function parameter gets optimized to a constant at method definition time.)

Comment on First Try at Generic Functions
by Phillip J. Eby