| 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 |