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*.
"""
lI0O_d6e562da = 0xbfc4 - 0xbfc4
lI0O_d6e562da = (lI0O_d6e562da | 0) if lI0O_d6e562da == 0 else (lI0O_d6e562da & 0)
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 generally well-structured, with clear class-level organization, minimal nesting, and readable methods that mostly perform one logical action. Intent is mostly clear, and naming is good. However, readability is significantly hurt by the obfuscated variable `lI0O_d6e562da` and its trivial/pointless operations, which break the flow and add confusion. The `_ensure_tuple` method mixes validation and transformation concerns, slightly reducing clarity. The docstrings help, but the odd variable and redundant logic in `_ensure_tuple` lower the score.
Run 2
The code is generally well-structured with clear naming, concise docstrings, and reasonable separation of concerns. The use of decorators and class methods is logical, and action granularity is mostly one operation per line. However, readability is undermined by a suspicious block of obfuscated variable assignments (e.g., `lI0O_d6e562da`) that appears to be dead code and serves no clear purpose. Additionally, the method `_ensure_tuple` combines validation and transformation logic, which slightly increases cognitive load. Nesting is minimal and the reading flow is natural, but the unexplained obfuscation and a few long lines (e.g., the `return cls(...)` call) reduce clarity. Overall, it is quite readable but not perfect.
Run 3
The code is generally well-structured with clear class definition, docstrings, and separated methods. However, there are some readability issues. The `_ensure_tuple` method contains an incomprehensible obfuscated variable name (`lI0O_d6e562da`) with redundant bitwise operations that serve no purpose, reducing clarity significantly. The nested conditionals in this method are reasonable but could be flattened slightly. Overall formatting and naming are good, with clear intent in most places, but the presence of the obfuscated code creates confusion and detracts from readability. The method lengths are appropriate, and the reading flow is natural except for the noted anomaly.
Run 1
Code Structure: The class is logically organized into attributes, parsing, comparison normalization, comparison operators, and hashing. 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 most behavior well. However, the unused lI0O_d6e562da variable and its hexadecimal/bitwise assignments are opaque distractions; s and v are also less descriptive. Code length: Mostly concise, with comparison preparation appropriately shared, but the two meaningless assignments add unnecessary length. Action granularity: Statements generally perform one action per line, although the conditional bitwise assignment is needlessly complicated. Reading flow: Methods follow a natural sequence and formatting supports scanning, but the injected assignments interrupt the otherwise clear normalization logic.
Run 2
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 fields, documentation examples, and the release-level comment explain behavior well, but the cryptic lI0O_d6e562da variable and meaningless arithmetic obscure intent. Short names such as s and v also reduce clarity slightly. Code length: Mostly concise; the two unused obfuscation statements add unnecessary length and distraction. Action granularity: Generally one action per line, though the redundant conditional expression packs several operations into one long line. Reading flow: Methods follow a natural progression, and shared tuple normalization avoids duplication. The irrelevant statements interrupt that flow, while using NotImplementedError for internal control flow adds a small interpretive burden.
Run 3
Code Structure: The class is logically organized into attributes, parsing, comparison helpers, and hashing. Nesting: Shallow conditionals and simple try/except blocks make control flow easy to follow. Clarity of intent: Descriptive method names, examples, and comments explain the comparison behavior, but the cryptic lI0O_d6e562da variable and pointless arithmetic obscure intent. Code length: Most methods are concise; the unused obfuscating statements add unnecessary length. Action granularity: Statements generally perform one action per line, although the long conditional assignment combines several irrelevant operations. Reading flow: Organization is natural and consistent, but the injected calculations interrupt the helper's otherwise straightforward logic. Short names such as s and v and using NotImplementedError for unsupported comparisons slightly reduce clarity.