Conditions | 5 |
Total Lines | 69 |
Lines | 0 |
Ratio | 0 % |
Changes | 1 | ||
Bugs | 0 | Features | 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 coala_decorators.decorators import generate_eq, generate_repr |
||
53 | @classmethod |
||
54 | def multiple(cls, *args): |
||
55 | """ |
||
56 | Creates a tuple of multiple instances of a class. |
||
57 | |||
58 | Should not be instances of ``PackageRequirement``, as this is an |
||
59 | abstract class: |
||
60 | |||
61 | >>> PackageRequirement.multiple(('pip', 'coala_decorators', '0.1.0'),) |
||
62 | Traceback (most recent call last): |
||
63 | ... |
||
64 | NotImplementedError |
||
65 | |||
66 | It can only be used for requirements of the same manager. For example, |
||
67 | consider a manager ``XYZRequirement`` that inherits from |
||
68 | PackageRequirement. This subclass will have the manager set to XYZ: |
||
69 | |||
70 | >>> class XYZRequirement(PackageRequirement): |
||
71 | ... manager = 'xyz' |
||
72 | ... def __init__(self, package, version=""): |
||
73 | ... PackageRequirement.__init__(self, package, version) |
||
74 | |||
75 | This is the case where you would provide strings only, to specify the |
||
76 | latest version automatically: |
||
77 | |||
78 | >>> REQUIREMENTS = XYZRequirement.multiple( |
||
79 | ... "package1", "package2") |
||
80 | |||
81 | And if you choose to mix them, specifying version for some and for some |
||
82 | not: |
||
83 | |||
84 | >>> REQUIREMENTS = XYZRequirement.multiple( |
||
85 | ... 'package1', ('package2', '2.0')) |
||
86 | |||
87 | Lists are also valid arguments: |
||
88 | |||
89 | >>> REQUIREMENTS = XYZRequirement.multiple( |
||
90 | ... ['package1', '1.0'],) |
||
91 | |||
92 | In case you provide too many arguments into the tuple, an error will be |
||
93 | raised: |
||
94 | |||
95 | >>> REQUIREMENTS = XYZRequirement.multiple( |
||
96 | ... 'package1', ('package2', '2.0', 'package3')) |
||
97 | Traceback (most recent call last): |
||
98 | ... |
||
99 | TypeError: Too many elements provided. |
||
100 | |||
101 | :param args: In the subclasses, the ``manager`` is already |
||
102 | specified, so they hould be iterables with two |
||
103 | elements: ``('packageName', 'version')`` or strings: |
||
104 | ``'packageName'`` if latest version is wanted. |
||
105 | :return: A tuple containing instances of the subclass. |
||
106 | :raises TypeError: In case the iterables contain more than two |
||
107 | elements. |
||
108 | """ |
||
109 | if cls == PackageRequirement: |
||
110 | raise NotImplementedError |
||
111 | else: |
||
112 | reqs = [] |
||
113 | for requirement in args: |
||
114 | if isinstance(requirement, str): |
||
115 | reqs.append(cls(requirement)) |
||
116 | elif len(requirement) == 2: |
||
117 | name, version = requirement |
||
118 | reqs.append(cls(name, version)) |
||
119 | else: |
||
120 | raise TypeError('Too many elements provided.') |
||
121 | return tuple(reqs) |
||
122 |