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 a(cls, c):
"""
Parse *s* and return a _VersionInfo.
"""
d = c.split(".")
if len(d) == 3:
d.append("final")
return cls(
year=int(d[0]), minor=int(d[1]), micro=int(d[2]), releaselevel=d[3]
)
def b(self, e):
"""
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 e.__class__:
e = astuple(e)
if not isinstance(e, tuple):
raise NotImplementedError
if not (1 <= len(e) <= 4):
raise NotImplementedError
return astuple(self)[: len(e)], e
def __eq__(self, f):
try:
g, h = self.b(f)
except NotImplementedError:
return NotImplemented
return g == h
def __lt__(self, i):
try:
j, k = self.b(i)
except NotImplementedError:
return NotImplemented
# Since alphabetically "dev0" < "final" < "post1" < "post2", we don't
# have to do anything special with releaselevel for now.
return j < k
def __hash__(self):
return hash((self.year, self.minor, self.micro, self.releaselevel))
Run 1
The code has some readability issues. The structure is logical with a single class and clear methods, but the naming conventions are poor: single-letter parameters (c, e, f, i) and local variables (d, g, h, j, k) obscure intent. The docstrings are misleading—'a' claims to parse *s* but takes parameter *c*, and there's no clear indication of what actions the methods perform based on their names. Method 'b' has multiple responsibilities (validation and transformation) and uses NotImplementedError for flow control, which is unusual. While nesting is minimal and each line generally performs one action, the constant need to mentally map cryptic names to types hampers reading flow. The version comparison logic in the tuple transformation is not immediately obvious. The class-level attributes are clear, and imports are clean, but the overall clarity of intent suffers significantly from the obfuscated naming throughout the methods.
Run 2
The code is generally readable with clear class structure, logical organization, and good use of decorators and type hints. The class docstring provides useful examples. However, readability is reduced by non-descriptive method and parameter names: 'a', 'b', 'c', 'e', 'f', 'g', 'h', 'i', 'j', 'k' are all unclear. The method 'b' performs multiple actions (type checking, validation, transformation) which affects action granularity. The parsing logic in 'a' is straightforward but the parameter name 'c' obscures intent. The code structure is flat and avoids deep nesting. Imports are organized. The docstrings help explain behavior, but the naming conventions significantly impact clarity of intent and reading flow. The code length is concise for what it does.
Run 3
The code has some positive aspects: it uses dataclass-like attrs, decorators for ordering, and keeps methods relatively short. However, readability is significantly harmed by meaningless variable names (a, b, c, d, e, f, g, h, i, j, k) and method names (a, b). The docstrings are unhelpful and sometimes misleading (e.g., 'Parse *s*' but argument is 'c', and the class docstring refers to attr.VersionInfo while code is VersionInfo). The b method mixes validation and transformation logic, making intent unclear. Nesting is shallow, which is good, but error handling and return logic add cognitive load. The class docstring examples are extensive but not directly tied to method behavior. Overall, the structure is logical but obscured by poor naming and inconsistent documentation, reducing clarity.
Run 1
Code Structure: The class logically groups version fields, parsing, comparison normalization, comparisons, and hashing. Nesting: Shallow conditionals and short try/except blocks are easy to follow. Clarity of intent: Descriptive fields, examples, and the release-order comment help, but methods a and b and variables c through k obscure their roles. The parsing docstring references s and _VersionInfo rather than the actual parameter and class, adding confusion. Code length: Compact overall, with useful documentation and little unnecessary implementation. Action granularity: Most lines perform one clear action; tuple unpacking and constructor arguments remain manageable. Reading flow: Methods follow a natural progression, but cryptic names require readers to repeatedly infer meanings, and using NotImplementedError as an internal comparison signal introduces some indirection.
Run 2
Code Structure: The class logically groups version fields, parsing, comparison normalization, comparison operators, and hashing. Nesting: Shallow conditionals and short try/except blocks keep complexity low. Clarity of intent: Descriptive field names, examples, and the release-level comment help, but methods a and b and variables c through k obscure their purposes. The parsing docstring references s and _VersionInfo instead of the actual parameter and class, adding confusion. Code length: Methods are concise, with little unnecessary repetition beyond the parallel comparison implementations. Action granularity: Most lines perform a single operation; tuple unpacking and the constructor call remain manageable. Reading flow: The progression from fields to parsing and comparison is natural, but cryptic identifiers force readers to repeatedly inspect implementations to understand relationships.
Run 3
Code Structure: The class logically groups version fields, parsing, comparison normalization, comparisons, and hashing. Nesting: Shallow conditionals and short try/except blocks keep complexity low. Clarity of intent: Descriptive field names, examples, and the release-level comment explain the purpose, but methods a and b and variables c through k obscure their roles. Docstrings also reference names absent from the signatures and inconsistently name the class. Code length: Methods are concise, with little unnecessary code; the long class docstring provides useful examples. Action granularity: Most lines perform one action, though constructor arguments are compressed onto one line. Reading flow: Organization is natural and consistent, but cryptic identifiers force readers to repeatedly infer meaning. Overall, the straightforward structure is readable despite substantial naming weaknesses.