[PEAK] Use cases for the priority feature

[Christoph Zwerschke]

Am 19.08.2010 01:33 schrieb P.J. Eby:
> One thought that's occurred to me is that if AmbiguousMethod errors
> included a friendly text explanation along the lines of, "hey, you
> forgot to define what happens if X and Y are both true; maybe you
> need a method with this rule: ... and spat out what you'd actually
> need to put in your rule to make it more specific, that would
> actually be more immediately helpful than making somebody have to
> figure it out, as is necessary now.

Yes, that would be a great help. What probably makes people 
uncomfortable with rules are the scary AmbigousMethod errors and the 
fact that you never know for sure when they will be raised in run time. 
Better errors messages plus a verification tool that could run as part 
of the test suite would make a lot of the scariness go away.

> I guess in summary, my feeling at this point is: there are use cases
> for priorities, but IMO they should be use-case specific, and the
> documentation should propose a couple different ways to do it for
> different sorts of use cases. But I don't think PEAK-Rules should
> actually *provide* a built-in priority mechanism, since there are so
> many ways to implement a custom one in only a few lines -- heck, the
> argument-based one doesn't require anything except adding an argument
> to your function and methods... which is just costly enough to make
> you consider whether you should be using it or not. ;-)
>
> I think, though, that we're basically in agreement that TurboJSON is
> *not* a valid use case for priorities in the first place: at worst,
> it's a use case for being able to replace or delete rules.

Agree on both points.

It cannot harm if the docs show more than one way to implement 
priorities, because they also demonstrate some of the more sophisticated 
functions and features slumbering within the package.

A recipe should also explain how to make methods being chosen 
unpredictably without error in case of ambiguity. There may be use cases 
where that is eligible, but of course it should never be the default 
behavior as it can hide rule errors and is unpythonic.

> 6. (Maybe) a @select_using mechanism, if we can come up with a
> satisfactory API. Perhaps something where you define a type for the
> metadata, and then *args and **kw from the when() decorators are
> passed into your metadata type constructor,

I like that idea. This allows you to easily create the same syntax as 
prioritized_methods which I prefer.

-- Christoph