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 from2(cls, s2):
"""
Parse *s* and return a _VersionInfo.
"""
v2 = s2.split(".")
if len(v2) == 3:
v2.append("final")
return cls(
year=int(v2[0]), minor=int(v2[1]), micro=int(v2[2]), releaselevel=v2[3]
)
def ensure(self, oth):
"""
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 self.__class__ is oth.__class__:
oth = astuple(oth)
if not isinstance(oth, tuple):
raise NotImplementedError
if not (1 <= len(oth) <= 4):
raise NotImplementedError
return astuple(self)[: len(oth)], oth
def __eq__(self, oth2):
try:
us2, the = self.ensure(oth2)
except NotImplementedError:
return NotImplemented
return us2 == the
def __lt__(self, oth3):
try:
us3, the2 = self.ensure(oth3)
except NotImplementedError:
return NotImplemented
# Since alphabetically "dev0" < "final" < "post1" < "post2", we don't
# have to do anything special with releaselevel for now.
return us3 < the2
def __hash__(self):
return hash((self.year, self.minor, self.micro, self.releaselevel))
Run 1
The code is generally clear and well-structured. It uses a flat hierarchy, each method has a single clear purpose, and lines are reasonably granular. The use of the `ensure` helper centralizes validation and normalization, avoiding repetitive logic. The class definition is concise thanks to the `attrs` decorators, and the docstrings with examples improve intent. Slight deductions: variable names like `oth`, `oth2`, `oth3` and `us2`, `us3` are short and obscure, reducing clarity compared to more descriptive alternatives. The `ensure` method has multiple validation checks that could be slightly more explicit, but they are linear rather than nested. Overall, the code is highly readable with minor naming and documentation improvements possible.
Run 2
The code is generally readable with clear class structure, logical method organization, and helpful docstrings. It uses decorators appropriately and keeps methods focused on single responsibilities. Nesting is minimal, though the ensure() method has sequential if-statements that could be simplified. Variable naming is inconsistent (oth, oth2, oth3, us2, us3, the, the2) which slightly obscures intent. Action granularity is mostly good, with one operation per line in parsing and comparisons. Some minor issues: the from2 parameter 's2' could be more descriptive, and the return statement in from2 spans multiple lines awkwardly. The reading flow is natural thanks to clear method ordering and explanatory comments. Overall, it's clean, maintainable code that would benefit from more consistent variable naming and slightly cleaner handling of edge cases.
Run 3
The code is well-structured and readable. It uses clear class-level attributes and decorators that convey intent. Methods are short, focused, and perform one logical action, with shallow nesting. Naming is generally clear, though abbreviated variables like 's2', 'v2', 'oth', 'us2', and 'the' slightly reduce clarity. The docstrings and examples improve understanding. The main readability weaknesses are inconsistent variable suffixes (oth, oth2, oth3; us2, us3) and a few slightly dense lines like the return of 'cls(...)' spanning multiple arguments. Overall, the code is concise, maintainable, and easy to follow.
Run 1
Code Structure: Well-organized class with separate parsing, comparison preparation, comparison, and hashing methods; shared logic avoids duplication. Nesting: Shallow conditionals and simple try/except blocks keep complexity low. Clarity of intent: Descriptive fields, examples, and the release-level comment explain behavior, but names such as from2, s2, oth3, us3, and the2 are cryptic. The parsing docstring also references names inconsistent with the implementation. Code length: Concise implementation; the longer class docstring provides useful examples rather than unnecessary verbosity. Action granularity: Most lines perform one action, although the constructor arguments are densely packed. Reading flow: Methods follow a natural progression, and early exits simplify reading. Unconventional use of NotImplementedError for unsupported comparisons adds a small comprehension burden.
Run 2
Code Structure: Well-organized class with distinct parsing, comparison normalization, comparison, and hashing methods. Nesting: Shallow conditionals and simple try/except blocks keep complexity low. Clarity of intent: The class docstring, examples, typed attributes, and release-level comment explain behavior well. However, names such as from2, s2, v2, oth2, us3, and the2 are cryptic and inconsistent; the parsing docstring also references names that differ from the implementation. Code length: Compact overall, with modest duplication between comparison methods. Action granularity: Most lines perform one clear action; the constructor groups several keyword arguments on one line but remains manageable. Reading flow: Methods follow a natural progression from construction to normalization and comparison. Decorator-generated behavior and using NotImplementedError as an internal control-flow signal require some additional interpretation.
Run 3
Code Structure: The class is logically organized into fields, parsing, comparison normalization, comparison operators, and hashing. Nesting: Shallow conditionals and short try/except blocks keep complexity low. Clarity of intent: The class docstring, examples, and release-level comment explain behavior well, but names such as from2, s2, oth3, us3, and the2 are unclear and inconsistent; the parsing docstring also references different names. Code length: Methods are concise, with only minor duplication between comparison operators. Action granularity: Most lines perform one action; the compact constructor call remains understandable. Reading flow: Methods follow a natural progression, although arbitrary numeric suffixes and using NotImplementedError for unsupported comparison operands introduce small comprehension hurdles.