[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