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 highly readable. It has a clear class structure with a focused responsibility: version representation and comparison. The `@attrs` and `@total_ordering` decorators simplify the class, avoiding boilerplate. Nesting is minimal—only necessary try/except blocks and one conditional. Intent is well-communicated through descriptive method names and docstrings with examples. The code is concise: methods are short and use helper functions (`_ensure_tuple`) to avoid repetition. Action granularity is mostly one action per line, with clean attribute assignments. The reading flow is logical, moving from class definition to parsing, validation, and comparison. Minor notes: `_from_version_string` has a hardcoded append of 'final' without obvious domain context, and `_ensure_tuple` mixes validation and transformation, but these are acceptable. Overall, the code is exemplary in clarity and maintainability.
Run 3
The code is well-structured and highly readable. The VersionInfo class uses clear class-level attributes and a logical grouping of methods. Nesting is shallow, with try/except blocks kept concise. Each method has a clear purpose, aided by docstrings and examples. Action granularity is generally one action per line, though the _from_version_string return statement packs multiple int conversions into one line, slightly reducing readability. The reading flow is natural, following class definition, attributes, constructor, helper, and comparison operators. Minor deductions for the slightly dense return statement and reliance on decorators/imports that may not be immediately obvious to unfamiliar readers, but overall the code is clear and maintainable.
Run 1
Code Structure: Well-organized class with distinct parsing, normalization, comparison, and hashing methods; shared comparison logic avoids duplication. Nesting: Shallow conditionals and straightforward try/except blocks make execution easy to follow. Clarity of intent: Descriptive method names, docstrings, examples, and the release-level comment explain behavior clearly, though abbreviated variables such as s and v and the exception-based unsupported-type signaling add minor ambiguity. Code length: Compact implementation with useful documentation and little unnecessary repetition. Action granularity: Statements generally perform one action per line; the constructor's multiple keyword arguments remain readable. Reading flow: Fields precede helper methods and comparison operations in a natural sequence. Minor distractions include the docstring referring to _VersionInfo rather than VersionInfo and reliance on decorator-generated behavior.
Run 2
Code Structure: The class is logically organized, with fields, parsing, shared comparison validation, comparison methods, and hashing clearly separated. Nesting: Shallow conditionals and short try/except blocks keep complexity low. Clarity of intent: Descriptive method names, docstrings, examples, and the release-level comment explain behavior well; abbreviated variables such as s and v slightly reduce clarity. Using NotImplementedError for internal control flow is less intuitive. Code length: Methods are concise, and shared validation avoids substantial duplication; the lengthy class docstring provides useful examples. Action granularity: Statements generally perform one action per line, with compact constructor arguments remaining readable. Reading flow: The progression from data definition through construction and comparison is natural and consistent, though understanding generated behavior requires familiarity with attrs and total_ordering.
Run 3
Code Structure: Well organized into a single cohesive class, with shared comparison preparation extracted into a helper. Nesting: Shallow conditionals and straightforward try/except blocks keep complexity low. Clarity of intent: Descriptive fields, docstrings, comparison examples, and a release-ordering comment explain the behavior clearly; abbreviated names such as s and v slightly reduce clarity. Code length: Concise overall, with useful documentation and minimal duplication between comparison methods. Action granularity: Statements generally perform one action each, and formatting separates operations cleanly. Reading flow: Fields, parsing, normalization, comparisons, and hashing follow a natural progression. Minor readability drawbacks include using NotImplementedError for internal control flow, requiring familiarity with attrs decorators, and a docstring referring to _VersionInfo rather than VersionInfo.