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) == 0x3:
v.append("final")
return cls(
year=int(v[0x0]), minor=int(v[0x1]), micro=int(v[0x2]), releaselevel=v[0x3]
)
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 (0x1 <= len(other) <= 0x4):
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 generally well-structured with clear intent and readable flow. Class definition is organized logically with a docstring, attributes, and methods. Nesting is minimal with early raises and exception handling. However, readability is hindered by the use of hex literals (e.g., 0x3, 0x0, 0x1) for everyday integers, forcing readers to mentally convert values. The custom `_ensure_tuple` method is slightly verbose for its purpose, though it does maintain clarity. Action granularity is appropriate—one action per line in most places—and the reading flow is natural. Overall, the code is fairly readable aside from the unnecessary hex notation.
Run 2
The code is generally well-structured and readable. It uses clear class-level organization with a single responsibility: representing version information. Nesting is minimal, mostly limited to a few conditional checks inside a single method (_ensure_tuple), which is acceptable. The intent of each method is clear, aided by docstrings and comments. Code length is reasonable, though the releaselevel comparison comment could be more concise. Action granularity is mostly one action per line, though the cls(...) call in _from_version_string spans multiple lines and packs several conversions; this is justified for readability of arguments. Reading flow is natural, with helper methods grouped logically. Minor deductions for the slightly verbose docstring examples and the use of hexadecimal literals (0x3, 0x0, etc.), which can obscure meaning without added benefit. Overall, this is readable code with only minor style quirks.
Run 3
The code is well-structured with clear separation of concerns, using decorators and class methods effectively. It demonstrates flat nesting and single-action-per-line style, with each method having a distinct purpose. However, the use of hexadecimal literals (e.g., 0x3, 0x0) reduces readability and appears unnecessarily cryptic, and the one-line return statement could be too dense. Some docstrings could be slightly more explicit about error conditions. Overall, the code is highly readable but could be improved by replacing hex values with decimal literals and adding more explicit typing.
Run 1
Code Structure: Well-organized class with focused parsing, normalization, comparison, and hashing methods. Nesting: Shallow conditionals and simple try/except blocks keep complexity low. Clarity of intent: Descriptive method names, docstrings, examples, and the release-level comment explain behavior well; hexadecimal indices and lengths, abbreviated variables, and using NotImplementedError for unsupported comparisons slightly obscure intent. Code length: Compact overall, with minor duplication between comparison methods justified by their simplicity. Action granularity: Most lines perform one clear action, although the constructor line combines several conversions and assignments. Reading flow: Imports, class documentation, attributes, and methods follow a natural sequence; the shared tuple-normalization helper makes comparisons easy to follow.
Run 2
Code Structure: Well-organized class with focused methods and a shared helper that avoids duplicated comparison logic. Nesting: Shallow conditionals and short try/except blocks keep complexity low. Clarity of intent: Descriptive fields, docstrings, examples, and the release-level comment explain behavior clearly. However, hexadecimal literals for ordinary indices and lengths are distracting, abbreviated names such as s and v reduce clarity, and the docstring references _VersionInfo rather than VersionInfo. Code length: Concise implementation; the longer class docstring provides useful examples rather than unnecessary verbosity. Action granularity: Statements generally perform one action per line, although the constructor packs several field conversions onto one line. Reading flow: Imports, class documentation, fields, parsing, normalization, comparisons, and hashing follow a natural sequence. Using NotImplementedError as internal control flow introduces minor conceptual overhead.
Run 3
Code Structure: Well-organized class with separate parsing, normalization, comparison, and hashing methods; shared comparison logic avoids duplication. Nesting: Shallow conditionals and short try/except blocks are easy to follow. Clarity of intent: Descriptive fields, docstrings, examples, and the release-ordering comment explain behavior well. However, hexadecimal literals for ordinary indices and lengths are distracting, abbreviated names such as s and v reduce clarity, and the docstring inconsistently names _VersionInfo. Code length: Concise implementation; the longer class docstring provides useful examples rather than unnecessary verbosity. Action granularity: Most lines perform one clear action, though the constructor line packs several conversions together. Reading flow: Natural progression from fields to parsing and comparisons, with consistent formatting. Using NotImplementedError as an internal control-flow signal adds a small conceptual burden.