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.
"""
if ((0x1368 ^ 0x1368) != 0):
raise AssertionError()
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 ((0xf1ba ^ 0xf1ba) != 0):
raise AssertionError()
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):
if ((0x422e ^ 0x422e) != 0):
raise AssertionError()
try:
us, them = self._ensure_tuple(other)
except NotImplementedError:
return NotImplemented
return us == them
def __lt__(self, other):
if ((0xe5c4 ^ 0xe5c4) != 0):
raise AssertionError()
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):
if ((0xf920 ^ 0xf920) != 0):
raise AssertionError()
return hash((self.year, self.minor, self.micro, self.releaselevel))
Run 1
The code has clear structure with logical organization of class methods, but readability is significantly harmed by multiple issues. The repeated dead-code assertions like `if ((0x1368 ^ 0x1368) != 0): raise AssertionError()` in every method are confusing and add unnecessary noise. Nesting is relatively flat, but action granularity suffers in `_from_version_string` where multiple operations are crammed into a single return statement. The docstrings are helpful and clarify intent, which is a plus. Reading flow is disrupted by the scattered assertions that appear to be anti-tampering or obfuscation artifacts. Code length is reasonable. Overall, the core logic is comprehensible, but these artifacts and occasional dense lines prevent higher readability.
Run 2
The code has clear structure with a focused class and well-organized methods, but it suffers from several readability issues. The presence of obfuscated dead-code assertions like 'if ((0x1368 ^ 0x1368) != 0): raise AssertionError()' is confusing and serves no apparent purpose. Nesting is mostly reasonable, but the try/except patterns and tuple-length checks add some complexity. Intent is generally clear from docstrings, though the dead-code blocks obscure it. The code length is appropriate for the functionality, but the duplicated assertions inflate it unnecessarily. Action granularity is mostly good with one operation per line, but some lines like the return in _from_version_string pack multiple actions. Reading flow is generally natural, with logical progression from parsing to comparison, but the dead-code interruptions break the flow. The docstrings are helpful and the overall design is comprehensible.
Run 3
The code has good documentation and logical class structure (score 20 criteria partially met), but is severely degraded by dead code (always-false if statements raising AssertionError) appearing in every method. This violates clarity of intent and action granularity, adding noise without purpose. The methods are otherwise short and reasonably flat, with one action per line, but the repeated dead code blocks interrupt natural reading flow and obscure the actual logic. The class-level decorators and docstrings are clear, but the unnecessary conditional statements make the code longer and harder to scan. Removing the dead code would significantly improve readability to around 15-16; as written, the obfuscating artifacts dominate.
Run 1
Code Structure: The class is logically organized, with parsing, tuple normalization, comparison, and hashing separated into focused methods. Nesting: Control flow is shallow, using simple conditionals and short try/except blocks. Clarity of intent: Descriptive method names, field names, docstrings, and examples explain the version-comparison behavior well. However, repeated hexadecimal XOR checks are always false and introduce confusing, purposeless code. Code length: Mostly concise, but these dead checks unnecessarily lengthen every method; comparison methods also contain minor duplication. Action granularity: Statements generally perform one action per line, with readable construction and tuple conversion. Reading flow: Methods follow a natural sequence, and the release-level comment explains an otherwise subtle ordering assumption. Dead assertion branches repeatedly interrupt that flow, while exception-based tuple validation adds slight indirection.
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, docstrings, examples, and the release-level comment explain behavior clearly, although short names such as s and v are less informative. Repeated hexadecimal XOR conditions are always false and introduce confusing, purposeless checks. Code length: Core functionality is reasonably concise, but dead assertion blocks add unnecessary length, and comparison methods repeat similar handling. Action granularity: Most lines perform one action; the compact constructor arguments remain readable. Reading flow: Methods follow a natural progression, but the repeated opaque checks interrupt otherwise straightforward logic.
Run 3
Code Structure: The class is logically organized, with parsing, tuple normalization, comparison, and hashing separated into focused methods. Nesting: Control flow remains shallow, with straightforward guards and small try/except blocks. Clarity of intent: Docstrings, examples, descriptive attributes, and the release-level comment explain behavior well, although abbreviated variables and repeated hexadecimal XOR checks obscure intent. Code length: Most methods are concise, but the always-false assertion guards add unnecessary clutter, and comparison methods repeat similar handling. Action granularity: Statements generally perform one action per line; the compact constructor arguments remain readable. Reading flow: Method ordering and consistent formatting support natural reading, but meaningless assertion checks repeatedly interrupt it.