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 well-structured with clear class definition, appropriate use of decorators, and focused methods. Nested logic is minimal, mostly using guard clauses and exception handling, which keeps the flow flat. Intent is clear through descriptive method names and docstrings with examples. Code length is reasonable—concise yet complete. Action granularity is appropriate; relevant actions are grouped logically, though a few lines could be slightly more explicit. Reading flow is natural, with helper methods separated from comparisons. Minor deductions for the `_ensure_tuple` return line relying on a tuple slice (less explicit) and the compact `return cls(...)` line, but overall readability is high.
Run 2
The code is well-structured and readable. It uses clear class-level attributes with type hints, has a single responsibility per method, and maintains a flat structure with minimal nesting. The helper method `_ensure_tuple` cleanly encapsulates validation and transformation logic, reducing duplication in comparison methods. Method names and docstrings clearly communicate intent. Action granularity is good — most lines perform one logical step. The reading flow is natural, though a few minor improvements would help: the `__lt__` comment is slightly distracting, and `_ensure_tuple` could be simplified by using a tuple of valid lengths instead of a range check. Overall, the code is concise, maintainable, and easy to follow.
Run 3
The code is highly readable with clear structure and intent. Class definition, attributes, and methods are logically organized with minimal nesting. Each method has a single responsibility and performs one action per line in most cases. Type hints and docstrings provide helpful context. The use of decorators and exception handling is clear. The longest method (_ensure_tuple) is still easy to follow due to flat control flow. Naming conventions are consistent and descriptive. The only minor weakness is the slightly cramped return statement in _from_version_string, but overall the code reads naturally from top to bottom.
Run 1
Code Structure: The class is logically organized into fields, parsing, comparison normalization, comparison methods, and hashing; shared logic avoids duplication. Nesting: Shallow conditionals and simple try/except blocks keep complexity low. Clarity of intent: Descriptive method names, docstrings, comparison examples, and the release-level comment explain behavior well, though short names like s and v and exception-based signaling slightly reduce clarity. Code length: Concise overall; the extensive examples provide useful documentation rather than unnecessary implementation length. Action granularity: Statements generally perform one action each; the compact constructor call remains readable. Reading flow: Methods follow a natural progression, with consistent formatting and straightforward control flow. Decorator behavior and the use of NotImplementedError as an internal signal require some background knowledge.
Run 2
Code Structure: The class is logically organized, with parsing, comparison normalization, comparison operators, and hashing separated into focused methods. Nesting: Shallow conditionals and simple try/except blocks keep complexity low. Clarity of intent: Descriptive fields, docstrings, examples, and the release-level comment explain behavior well; abbreviated names such as s and v slightly reduce clarity. Using NotImplementedError for internal control flow is somewhat unconventional. Code length: Concise overall, with useful documentation and minimal duplication between comparison methods. Action granularity: Most lines perform one action; the constructor groups several keyword arguments without becoming difficult to read. Reading flow: Imports, decorators, fields, and methods follow a natural progression, and the shared tuple-normalization helper makes comparisons easy to follow. Minor issues include the docstring referring to _VersionInfo rather than VersionInfo and the need to understand decorator-generated behavior.
Run 3
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 execution paths easy to follow. Clarity of intent: Descriptive method and field names, docstrings, examples, and the release-level comment explain behavior well. Short names such as s and v, a mismatched _VersionInfo reference, and using NotImplementedError for unsupported operands slightly reduce clarity. Code length: Compact implementation with useful documentation rather than unnecessary verbosity. Action granularity: Statements generally perform one action each; the constructor arguments remain readable despite sharing a line. Reading flow: Imports, decorators, fields, and methods follow a natural sequence, with consistent spacing and straightforward returns. Decorator-generated behavior requires some familiarity with attrs and total_ordering.