[PEAK] Re: dispatch rules based of the current scope.
Phillip J. Eby
pje at telecommunity.com
Sun Mar 19 16:20:38 EST 2006
At 08:08 PM 3/19/2006 +0100, Elvelind Grandin wrote:
>On 3/19/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 03:57 PM 3/19/2006 +0100, Elvelind Grandin wrote:
> > >Hi.
> > >
> > >One thing that supriced me in rulesdispatch was this.
> > >
> > >foo = generic()(foo)
> > >a = 1
> > >foo.when("a ==1")(print1)
> > >foo.when("a ==2")(print2)
> > >
> > >a = 2
> > >foo()
> > > >> 1
> > >
> > >is there any clever way of doing this besides putting a into the
> > >signature of the foo function?
> >
> > Yes; make it a zero argument callable, e.g. "lambda: a". Zero-argument
> > callables are assumed to be dynamic; all other expressions that *can* be
> > computed statically, *will* be.
>hm.
>do you mean make a lambda as in a = lambda: or use it in the .when call?
f = lambda: a
when( f()==1 )
> > >For my turbogears decorator that uses ruledispath I would like to
> > >allow an custom_rule argument. but that rule need to be evaled in the
> > >context of a request so you can dispatch based on header info etc.
> >
> > As long as some part of the expression is a zero-argument callable,
> > dependent subexpressions will be evaluated at dispatch time. e.g.
> > "get_request().foo" will be entirely evaluated at runtime.
More information about the PEAK
mailing list