[Cython] Some small phase refactorings

Dag Sverre Seljebotn dagss at student.matnat.uio.no
Wed May 7 08:46:25 CEST 2008


> I think one could put a generic accept function in the Node class  
> that would dispatch based on class name (or some class attribute) if  
> one wanted, rather than having to write it for every class.
>   
Yes, simply move the function. You spoke against using the class name in 
the other thread though. I suppose I could use an attribute; still I 
like decorators much better.

> I think this is good to talk about now. Basically, you want to change  
> Cython to use the "visitor pattern" rather than the recursive pattern  
> that it currently uses. This has pros and cons, but I think this  
> could be a good thing, and you are certainly convinced that its  
> needed to get started on the GSoC stuff. Something doesn't sit right  
> about the patch though, but I can't quite put my finger on it. I  
> think that it should happen at a higher level than inside the module  
> node (i.e. ModuleNode should be "visited" rather than initiate the  
> visitors.) As for the "phase shift" between function bodies and the  
>   
But of course! I'll repeat what I said to Stefan (the context is the 
codelines in ModuleNode.py):

---

Note that this code will almost certainly be moved again and  
rewritten at
some later point (they can't really belong to ModuleNode); but more
refactoring must happen before they can be moved to their proper  
location
and they serve a good purpose where they are for now though.

---

It's a rather big knot, and one has to begin to untangle it somewhere. I 
chose in the middle of ModuleNode.

One could make a (perhaps more natural) decision to start untangle it at 
the top (i.e. in Main.py); however two things spoke against it:

- I wanted to jump right in and have a feel for the most difficult phase 
seperation we were going to transform. If I started at the top, I would 
have to refactor ModuleNode before going on, and that would take some 
time yet still be a (comparatively) easy task -- and I wouldn't get time 
there and then for challenging refactoring the main tree and see what 
the real issues were. So I wouldn't gain any real new knowledge from 
starting "at the right place" (which was needed at this stage, in order 
to start thinking about this refactoring).

-  It will also take some longer to see the immediate gains one gets 
from this starting from the top, but that is fine...

Of course, different needs drive Cython patch inclusion than what I need 
to investigage; and I'm fine with the patch not being included at this 
stage.


-- 
Dag Sverre



More information about the Cython-dev mailing list