On Tue, Aug 17, 2010 at 5:48 PM, Robert Bradshaw <[email protected]> wrote: > On Tue, Aug 17, 2010 at 5:35 PM, Carl Witty <[email protected]> wrote: >> Well, Stefan's patch essentially reverts the part of my patch dealing >> with __getattr__. So this definitely fixes any __getattr__-related >> regressions, at the cost of not fixing the particular performance bug >> that was the reason for my patch (the one that William was so unhappy >> about on sage-devel). >> >> I have an idea for another patch that might make everyone happy. >> After calling PyType_Ready, copy __getattribute__ (the wrapper object >> provided by Python) to __getattr__; then the type has a __getattr__, >> so Stefan's code should work, but it's a Python wrapper object, which >> will hopefully avoid the performance problem on subclasses. (I'm not >> sure what this would do with respect to the docstring issue Stefan >> mentioned.) > > Copying it over isn't the right solution as __getattr_ is different > than __getattribute__, and only the latter is created for a tp_getattr > slot. I think that providing our own __getattr__ wrapper will not > impact the performance of __getattribute__ (the important case), but > this needs to be tested.
I'm really quite sure that the performance bug was due to a Cython-created __getattr__ wrapper. In detail: when you create a non-cdef subclass of a cdef class with __getattr__, Python has to decide what to stick in the tp_getattro slot. It notices that there's a __getattr__ defined (that's not a Python-created wrapper object), and so it puts in a generic function that looks up __getattribute__ and __getattr__ in the type dictionary. I guess copying __getattribute__ to __getattr__ would slightly change the behavior when somebody accessed __getattr__ directly. (It wouldn't change the behavior of normal attribute lookup on the object.) With the current cython-devel we could probably fix the Sage __getattr__ performance issue by changing Parent and Element to define __getattribute__ instead of __getattr__. (Maybe this is what you were saying?) Carl _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
