[Python-3000] Sane transitive adaptation

Ian Bicking ianb at colorstudy.com
Thu Apr 6 19:16:31 CEST 2006


Phillip J. Eby wrote:
> At 08:51 AM 4/6/2006, Ian Bicking <ianb at colorstudy.com> wrote:
> 
>> So... in theory you could register strings, and thus implement
>> RuleDispatches behavior (where those strings represent expressions).
>> Or, ideally, py3k will have something better than strings to represent
>> unevaluated expressions.  Though there's lots of optimizations in
>> RuleDispatch that would be lost when abstracted in this way.
> 
> 
> I wouldn't worry about that.  Give me an AST and the ability to edit and 
> compile it, and I'll move the world.  :)

I was thinking about how RuleDispatch might extend built-in type-based 
generic functions, and I don't think you'd have the opportunity to do 
the same optimizations.  That is, instead of RuleDispatch providing an 
alternate decorator, it would simply provide an alternate kind of predicate.

My understanding of RuleDispatch is that given two predictaes "foo(a) > 
10" and "foo(a) < 20", you calculate "foo(a)" once and apply both 
comparisons on that value.  And that you also combine predicates to 
create a decision tree.  However, if all RuleDispatch can do is give 
opaque boolean-producing functions for its predicates, the generic 
function machinery would have to scan through all predicates to 
determine what matched and if there was any ambiguity (except for the 
occasional condition you wouldn't have to test because of a dominance 
relationship).

> Really, if functions had a writable 'func_ast' attribute, RuleDispatch 
> could be a *lot* simpler than it currently is.  Even the syntax would be 
> better, since when() could take a lambda function, and I thus wouldn't 
> have to do string parsing or have the mini-interpreter.  RuleDispatch 
> could just manipulate the ASTs.

I personally would very much like a general syntax and associated 
support for unevaluated (and maybe unevaluatable) expressions, beyond 
just lambda; RuleDispatch is one of several projects already consuming 
such expressions.  But that's a separate topic I was hoping to bring up 
once the generic function/adapter discussion died down some.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Python-3000 mailing list