[Cython] Some small phase refactorings

[Robert Bradshaw]

On May 6, 2008, at 11:46 PM, Dag Sverre Seljebotn wrote:

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

Yes, I do to. I'm not totally dead set against them either. I just  
sent out a (much more explicit) email on this note, if it doesn't get  
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.

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

You're reasoning makes sense here, as long as it doesn't make it more  
difficult to move things up to the top at the end.

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


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

- Robert