[Cython] Some small phase refactorings

[Dag Sverre Seljebotn]

> any replies than I guess that's an indication. I am actually a bit  
> worried about how the use of decorators will impact the ability of  
> Cython to compile itself into ultra-efficient C.
>   
Efficiency doesn't bother me at all, and I have reasons! What the 
decorators would do (does, in prototype code) is stuff the class name 
and function into a dictionary at *class construction time* (or, without 
metaclass support, at object construction time), i.e. a O(1) overhead 
that is negligible even when running in the Python interpreter. During 
tree traversal, it's just a dict lookup on class id and a dispatch to 
the resulting function.

If one were generating C++ objects then the classical visitor pattern 
would be faster because real vtables are faster than dict lookups, 
however Cython polymorphism is (if I'm not wrong, haven't looked at this 
closely) dict-based anyway so it shouldn't make a difference.

Here's another way to use 2.3 that might be acceptable:

class WithStatementHandler(VisitorTransform):
    def handle_with(self, node): ...

    matches = [
        class_match(WithStatementNode, handle_with)
    ]


It would end up as a dict of class -> function like the other approach 
(but written like a list of objects because I'd like to leave a way open 
up for other types of matches though).

> It just didn't seem to add anything except another level of  
> indirection, but that will of course eventually be needed. There is a  
> lot of re-factoring that will need to be done. I've just got other  
> obligations (general exam) to be able to put much time/though into  
> this for the next two weeks or so :-(.
>   
What it added was the capability to plug in new transforms after type 
analysis, but before generation, on a module-wide basis, rather than 
having the transform run once for each function.

I didn't make that very clear; I suppose because you're right, it's real 
value is in another layer of indirection -- but one that will be needed 
and is useful during refactoring, and can allow "in-production" 
refactoring, rather than applying it all at once.

" The only problem that cannot be solved by another layer of indirection 
is too many layers of indirection " :-)

-- 
Dag Sverre