Hi! Just to show you what speed differences we are talking about, consider a situation were we see the overhead in its purest form:
sage: class Bar(object): ....: def pure_method(self): ....: return 1 ....: @property ....: def test_property(self): ....: return 2 ....: @lazy_attribute ....: def test_lazy(self): ....: return 3 ....: @cached_method ....: def test_cache(self): ....: return 4 ....: def __init__(self): ....: self.test_attrib = 5 ....: sage: b = Bar() sage: b.pure_method() 1 sage: b.test_property 2 sage: b.test_lazy 3 sage: b.test_cache() 4 sage: b.test_attrib 5 sage: %timeit b.test_property 625 loops, best of 3: 967 ns per loop sage: %timeit b.pure_method() 625 loops, best of 3: 934 ns per loop sage: %timeit b.test_cache() 625 loops, best of 3: 291 ns per loop sage: %timeit b.test_lazy 625 loops, best of 3: 192 ns per loop sage: %timeit b.test_attrib 625 loops, best of 3: 174 ns per loop Note that I am using #11115. Without #11115, b.test_cache() would take 1.7 µs. Since super_categories and all_super_categories are called really often, I think they should be as fast as possible. But on the other hand, in some cases they are not called at all. Hence, it would be a bad idea to create a *non-lazy* attribute during initialisation of a category. So, for sure my suggestion at #11943 is good for performance. The question on "being pythonic" has been answered affirmatively. The only remaining questions are: Should we renounce the speed-up for introspection's sake? Renounce introspection for speed's sake? Or is it possible to modify the preparser (or some other tool) so that we both have the speed-up and make `C.super_categories?` show the source of the *method/property/...* (not the source code of the return value)? Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
