Source code
from functools import total_ordering
from ._funcs import astuple
from ._make import attrib, attrs
@total_ordering
@attrs(eq=False, order=False, slots=True, frozen=True)
class VersionInfo:
"""
A version object that can be compared to tuple of length 1--4:
>>> attr.VersionInfo(19, 1, 0, "final") <= (19, 2)
True
>>> attr.VersionInfo(19, 1, 0, "final") < (19, 1, 1)
True
>>> vi = attr.VersionInfo(19, 2, 0, "final")
>>> vi < (19, 1, 1)
False
>>> vi < (19,)
False
>>> vi == (19, 2,)
True
>>> vi == (19, 2, 1)
False
.. versionadded:: 19.2
"""
year = attrib(type=int)
minor = attrib(type=int)
micro = attrib(type=int)
releaselevel = attrib(type=str)
@classmethod
def _from_version_string(cls, s):
"""
Parse *s* and return a _VersionInfo.
"""
v = s.split(".")
if not (len(v) == 3):
pass
else:
v.append("final")
return cls(
year=int(v[0]), minor=int(v[1]), micro=int(v[2]), releaselevel=v[3]
)
def _ensure_tuple(self, other):
"""
Ensure *other* is a tuple of a valid length.
Returns a possibly transformed *other* and ourselves as a tuple of
the same length as *other*.
"""
if not (self.__class__ is other.__class__):
pass
else:
other = astuple(other)
if not (not isinstance(other, tuple)):
pass
else:
raise NotImplementedError
if not (not (1 <= len(other) <= 4)):
pass
else:
raise NotImplementedError
return astuple(self)[: len(other)], other
def __eq__(self, other):
try:
us, them = self._ensure_tuple(other)
except NotImplementedError:
return NotImplemented
return us == them
def __lt__(self, other):
try:
us, them = self._ensure_tuple(other)
except NotImplementedError:
return NotImplemented
# Since alphabetically "dev0" < "final" < "post1" < "post2", we don't
# have to do anything special with releaselevel for now.
return us < them
def __hash__(self):
return hash((self.year, self.minor, self.micro, self.releaselevel))
Run 1
The code has some readability strengths, including clear docstrings, type hints, and a logical class structure. However, it suffers from several significant issues. The use of negated conditionals with empty 'pass' blocks (e.g., 'if not (len(v) == 3): pass else: ...') is confusing and unnecessarily inverted, making the logic harder to follow. This same pattern appears multiple times in '_ensure_tuple', creating tangled control flow. The '_from_version_string' method lacks input validation and has an unclear flow. The comment about releaselevel ordering in __lt__ is helpful but the actual comparison logic could be more explicit. Variable naming is generally good, and the class decorators are clear. Overall, while the intent can be understood, the unnecessarily inverted conditionals and empty blocks significantly impair readability, forcing readers to mentally invert logic multiple times.
Run 2
The code has clear intent and docstrings, but suffers from awkward branching. The `if not condition: pass else: ...` pattern in `_ensure_tuple` and `_from_version_string` is inverted and confusing; it forces readers to mentally negate the condition. This creates unnecessary nesting and obscures the actual logic. The multiple actions on one line in `_from_version_string`’s `return` reduce clarity. Class structure and imports are logical, and the comparison methods are straightforward, but the helper methods’ flow is unnatural. Overall, readable in parts but significantly hindered by the inverted conditionals.
Run 3
The code has a clear structure with logical imports, class-level attributes, and method grouping. However, readability is undermined by awkward inverted conditional patterns like 'if not (len(v) == 3): pass else: ...' which obscure intent and create unnecessary nesting. The _ensure_tuple method has flat but puzzling logic with multiple inverted checks and empty pass blocks, making the control flow hard to follow. The docstrings and comments generally aid understanding, and the version comparison logic is concise. Variable names are descriptive, but the conditional style significantly hurts the natural reading flow. Action granularity is mostly one action per line, which is good, but the overall clarity is reduced by the unnecessarily convoluted conditionals. The code is not deeply nested but could be more readable by replacing inverted 'if not' patterns with straightforward positive checks.
Run 1
Code Structure: Well-organized class with focused parsing, normalization, comparison, and hashing methods. Nesting: Shallow overall, though unnecessary if/else branches with pass add visual clutter. Clarity of intent: Descriptive method names, docstrings, examples, and the release-level comment explain behavior well; repeated negations, especially double and triple negatives in validation, obscure straightforward conditions. Short names such as s and v slightly weaken clarity. Code length: Mostly concise, but redundant branches unnecessarily lengthen simple checks. Action granularity: Generally one action per line, with constructor arguments grouped appropriately. Reading flow: Methods follow a logical progression, and comparisons consistently reuse the normalization helper. However, inverted conditions and exception-based handling of unsupported operands interrupt otherwise natural reading.
Run 2
Code Structure: Responsibilities are logically separated into parsing, tuple normalization, comparison, and hashing methods. Nesting: Depth is shallow, but repeated empty pass branches and else blocks introduce unnecessary branching. Clarity of intent: Descriptive method names, documentation, and comparison examples explain the purpose well; double and triple negations in conditions substantially obscure otherwise simple checks. Code length: The class is reasonably compact, although inverted conditions and no-op branches add avoidable lines. Action granularity: Most statements perform one action, and the compact constructor call remains understandable. Reading flow: Field declarations and method ordering are natural, but readers must repeatedly untangle negations and skip empty branches. Direct conditions and straightforward validation would significantly improve readability.
Run 3
Code Structure: The class is logically organized into fields, parsing, normalization, comparison, and hashing methods. Nesting: Depth is shallow, but redundant if/pass/else branches add unnecessary complexity. Clarity of intent: Docstrings, examples, and descriptive field names explain the purpose well; repeated negations obscure otherwise simple conditions, and abbreviated variables reduce clarity. Code length: Mostly compact, but empty branches and convoluted checks unnecessarily inflate the implementation. Action granularity: Most lines perform one action, although the constructor packs several arguments together. Reading flow: Method ordering and shared comparison normalization support natural reading, but inverted conditions repeatedly interrupt it. Overall, the design is understandable, while the conditional style significantly undermines readability.