Efficiency does matter to Sage though, and an O(1) overhead is very far from negligible. Cython uses real C vtables, so there are absolutely no dict-based lookups involved with cdef class polymorphism. -Infinity to any proposal that makes code slower.
On Thu, May 8, 2008 at 11:50 AM, Dag Sverre Seljebotn <[EMAIL PROTECTED]> wrote: > >> 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 > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
