Conditions | 8 |
Total Lines | 83 |
Lines | 0 |
Ratio | 0 % |
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
1 | from __future__ import absolute_import, division, print_function |
||
65 | def memoizemethod(method): |
||
66 | """ |
||
67 | Decorator to cause a method to cache it's results in self for each |
||
68 | combination of inputs and return the cached result on subsequent calls. |
||
69 | Does not support named arguments or arg values that are not hashable. |
||
70 | |||
71 | >>> class Foo (object): |
||
72 | ... @memoizemethod |
||
73 | ... def foo(self, x, y=0): |
||
74 | ... print('running method with', x, y) |
||
75 | ... return x + y + 3 |
||
76 | ... |
||
77 | >>> foo1 = Foo() |
||
78 | >>> foo2 = Foo() |
||
79 | >>> foo1.foo(10) |
||
80 | running method with 10 0 |
||
81 | 13 |
||
82 | >>> foo1.foo(10) |
||
83 | 13 |
||
84 | >>> foo2.foo(11, y=7) |
||
85 | running method with 11 7 |
||
86 | 21 |
||
87 | >>> foo2.foo(11) |
||
88 | running method with 11 0 |
||
89 | 14 |
||
90 | >>> foo2.foo(11, y=7) |
||
91 | 21 |
||
92 | >>> class Foo (object): |
||
93 | ... def __init__(self, lower): |
||
94 | ... self.lower = lower |
||
95 | ... @memoizemethod |
||
96 | ... def range_tuple(self, upper): |
||
97 | ... print('running function') |
||
98 | ... return tuple(i for i in range(self.lower, upper)) |
||
99 | ... @memoizemethod |
||
100 | ... def range_iter(self, upper): |
||
101 | ... print('running function') |
||
102 | ... return (i for i in range(self.lower, upper)) |
||
103 | ... |
||
104 | >>> foo = Foo(3) |
||
105 | >>> foo.range_tuple(6) |
||
106 | running function |
||
107 | (3, 4, 5) |
||
108 | >>> foo.range_tuple(7) |
||
109 | running function |
||
110 | (3, 4, 5, 6) |
||
111 | >>> foo.range_tuple(6) |
||
112 | (3, 4, 5) |
||
113 | >>> foo.range_iter(6) |
||
114 | Traceback (most recent call last): |
||
115 | TypeError: Can't memoize a generator or non-hashable object! |
||
116 | """ |
||
117 | |||
118 | @wraps(method) |
||
119 | def _wrapper(self, *args, **kwargs): |
||
120 | # NOTE: a __dict__ check is performed here rather than using the |
||
121 | # built-in hasattr function because hasattr will look up to an object's |
||
122 | # class if the attr is not directly found in the object's dict. That's |
||
123 | # bad for this if the class itself has a memoized classmethod for |
||
124 | # example that has been called before the memoized instance method, |
||
125 | # then the instance method will use the class's result cache, causing |
||
126 | # its results to be globally stored rather than on a per instance |
||
127 | # basis. |
||
128 | if '_memoized_results' not in self.__dict__: |
||
129 | self._memoized_results = {} |
||
130 | memoized_results = self._memoized_results |
||
131 | |||
132 | key = (method.__name__, args, tuple(sorted(kwargs.items()))) |
||
133 | if key in memoized_results: |
||
134 | return memoized_results[key] |
||
135 | else: |
||
136 | try: |
||
137 | result = method(self, *args, **kwargs) |
||
138 | except KeyError as e: |
||
139 | if '__wrapped__' in str(e): |
||
140 | result = None # is this the right thing to do? happened during py3 conversion |
||
141 | else: |
||
142 | raise |
||
143 | if isinstance(result, GeneratorType) or not isinstance(result, Hashable): |
||
144 | raise TypeError("Can't memoize a generator or non-hashable object!") |
||
145 | return memoized_results.setdefault(key, result) |
||
146 | |||
147 | return _wrapper |
||
148 | |||
297 |