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 len(v) == 3:
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 self.__class__ is other.__class__:
other = astuple(other)
if not isinstance(other, tuple):
raise NotImplementedError
if not (1 <= len(other) <= 4):
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 is highly readable with a clear logical structure: class definition, attributes, classmethod, helper, then dunder comparisons. Nesting is minimal (try-except with a single if-guard). Intent is explicit through descriptive method and variable names. Code length is concise without unnecessary verbosity. Each line generally performs one action, enhancing clarity. The reading flow is natural due to consistent organization and docstrings explaining non-obvious logic.
Run 2
The code is well-structured and highly readable. It uses clear class-level attributes with type hints, logical method organization, and consistent error handling. Nesting is minimal: each method has at most one level of indentation beyond the method body. Helper methods like `_ensure_tuple` encapsulate validation and normalization, keeping comparison methods concise. Action granularity is good—each line generally performs one meaningful operation. Reading flow is natural: parsing, validation, then comparison logic. The docstrings are informative and the inline comment explains a non-obvious release-level ordering decision. Minor deductions: the `_ensure_tuple` method returns a slice of the internal tuple, which relies on understanding `astuple` behavior; and the class-level `attrib` declarations could be slightly more compact, though they aid clarity. Overall, the code is approachable for someone familiar with Python.
Run 3
The code is highly readable, with a clean logical structure: class-level attributes are defined clearly using the `attrib` helper, and methods are short and focused. It benefits from flat nesting with only one level of exception handling and minimal indentation. Intent is clear throughout, supported by docstrings and comments explaining non-obvious logic, such as releaselevel ordering. Code length is appropriate—no unnecessary repetition or bloat. Each line performs a single logical action, especially in parsing and tuple conversion. Reading flow is natural, moving from class definition to attribute declarations, then helper methods and comparison operators. Minor deductions come from slight complexity in `_ensure_tuple` (multiple validation steps and exception control) and the use of `NotImplementedError` inside a helper method, which can obscure control flow for less experienced readers.
Run 1
Code Structure: Well-organized class with distinct parsing, normalization, comparison, and hashing methods; shared comparison logic avoids duplication. Nesting: Shallow conditionals and simple try/except blocks keep complexity low. Clarity of intent: Descriptive method names, field names, docstrings, examples, and a release-order comment explain behavior well, though abbreviated variables such as s and v are less expressive. Code length: Concise implementation; the longer docstring provides useful examples rather than unnecessary verbosity. Action granularity: Statements generally perform one action per line; the compact constructor call remains readable. Reading flow: Imports, decorators, fields, and methods follow a natural sequence. Minor readability drawbacks include reliance on decorator-generated behavior and using NotImplementedError as internal control flow.
Run 2
Code Structure: Well-organized class with focused parsing, normalization, comparison, and hashing methods; shared comparison logic avoids duplication. Nesting: Shallow conditionals and simple try/except blocks keep complexity low. Clarity of intent: Descriptive method and attribute names, useful docstrings, examples, and a release-ordering comment explain behavior clearly. Short names such as s and v and exception-based signaling in _ensure_tuple slightly reduce clarity. Code length: Concise implementation; the longer class docstring provides valuable usage examples rather than unnecessary detail. Action granularity: Most lines perform one action, with compact constructor arguments remaining easy to follow. Reading flow: Imports, decorators, attributes, and methods appear in a natural sequence. Decorator-generated behavior requires some library familiarity, and the parsing docstring inconsistently names _VersionInfo instead of VersionInfo.
Run 3
Code Structure: Well-organized class with clearly separated parsing, comparison normalization, comparison operators, and hashing. Nesting: Shallow conditionals and straightforward try/except blocks keep complexity low. Clarity of intent: Descriptive fields, docstrings, comparison examples, and the release-level comment explain behavior well. Short names such as 's', 'v', and 'us' slightly reduce clarity, and using NotImplementedError as an internal control-flow signal is less intuitive. Code length: Concise implementation with useful documentation; duplicated comparison handling is minor. Action granularity: Statements generally perform one action per line, and the compact constructor call remains readable. Reading flow: Fields and methods follow a natural progression, with consistent formatting and helpful spacing. Decorator-generated behavior requires some familiarity with attrs and total_ordering.