[Python-3000] Sane transitive adaptation

Phillip J. Eby pje at telecommunity.com
Thu Apr 6 18:59:57 CEST 2006


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.  :)

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.

My plans for future versions of RuleDispatch had called for using 
bytecode generation in order to produce more specialized dispatch 
patterns based on the configuration and use of a particular function; 
it would be *so* nice not to have to do it with bytecode.

In fact, the only other dream feature I'd ask for to make 
RuleDispatch complete would be an AST abstraction for a hash table 
lookup; i.e., an optimized form of:

     if x==int:
         ...
     elif x==str:
         ...

That is, I'd like to be able to put a structure like the above in a 
while loop that's walking something's mro, and have it be as 
efficient as doing a dictionary lookup that just branched within the 
function instead of incurring a function call overhead to do a 
table-based dispatch.

With that ability (which could also just be that setting func_ast to 
such a dispatch tree automatically optimized the if-elifs to a 
"computed goto"), RuleDispatch wouldn't have to create a special 
"dispatch tree" structure except during compilation -- the AST would 
be the runtime dispatch tree.  And, Psyco-style, it could leave some 
branches of the AST unexpressed except for a stub that requests that 
branch be built out at runtime.  In other words, delayed 
specialization for unneeded branches.




More information about the Python-3000 mailing list