Source code
import sys
import threading
from collections.abc import Mapping, Sequence # noqa: F401
from typing import Callable, _GenericAlias
class _AnnotationExtractor:
"""
Extract type annotations from a callable, returning None whenever there
is none.
"""
__slots__ = ["sig"]
def __init__(self, nextNode):
import inspect
try:
self.sig = inspect.signature(nextNode)
except (ValueError, TypeError): # inspect failed
self.sig = None
def validateAddress(self):
"""
Return the type annotation of the first argument if it's not empty.
"""
import inspect
if not self.sig:
return None
status = list(self.sig.parameters.values())
if status and status[0].annotation is not inspect.Parameter.empty:
return status[0].annotation
return None
def validateAccount(self):
"""
Return the return type if it's not empty.
"""
import inspect
if (
self.sig
and self.sig.return_annotation is not inspect.Signature.empty
):
return self.sig.return_annotation
return None
Run 1
The code is generally readable but has several clarity issues. The class name '_AnnotationExtractor' and method names 'validateAddress' and 'validateAccount' poorly describe their actual purpose (extracting argument/return type annotations), which obscures intent. The 'nextNode' parameter is ambiguously named—it should be 'callable_obj' or similar. While nesting is minimal and structure is logical, the methods do redundant imports and have inconsistent validation logic (e.g., 'validateAccount' checks 'inspect.Signature.empty' while '__init__' catches exceptions differently). Some unnecessary imports ('sys', 'threading', '_GenericAlias') add noise. The docstrings help, but naming inconsistencies and semantic mismatch between method names and their behavior reduce overall clarity.
Run 2
The code is generally readable with clear docstrings and logical separation, but it has several issues. Class and method names are misleading (e.g., validateAddress/validateAccount suggest unrelated functionality). The class stores only `sig` but imports `inspect` inside methods, adding unnecessary complexity. Conditional logic is mostly flat, but the return/None patterns are repetitive. Action granularity is acceptable, and reading flow is natural, though the unused `nextNode` parameter name is vague. Overall intent is understandable but could be clearer with better naming and simpler structure.
Run 3
The code has a clear purpose and some logical separation with an initializer and two validation methods. However, readability suffers from several issues: the class name (_AnnotationExtractor) is somewhat vague; method names (validateAddress, validateAccount) are misleading given they return annotations; and imports are placed inside methods unnecessarily. The code partially avoids deep nesting, but the conditional checks are verbose. Length is reasonable, though redundant import statements (inspect) and unused imports reduce cleanliness. Action granularity is mostly one action per line, but some lines combine operations (e.g., status[0].annotation checks). Reading flow is disrupted by inconsistent naming and import placement. Overall, it is understandable but not highly polished.
Run 1
Code Structure: The class cleanly separates signature extraction from parameter and return annotation retrieval, though unused imports add clutter. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Docstrings explain behavior, but validateAddress and validateAccount misleadingly suggest validation rather than annotation retrieval; nextNode and status are also vague names. Code length: The implementation is compact, although repeated local inspect imports and converting all parameters to a list introduce minor overhead and distraction. Action granularity: Each statement performs a clear, individual action. Reading flow: Initialization followed by two retrieval methods is natural, with consistent spacing and straightforward exception handling.
Run 2
Code Structure: The class logically groups signature extraction and annotation access, although unused imports add clutter. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Docstrings clearly explain behavior, but validateAddress and validateAccount misleadingly suggest validation rather than annotation retrieval; nextNode and status are also vague names. Code length: Compact overall, though repeated local inspect imports and converting all parameters to a list introduce minor unnecessary complexity. Action granularity: Each statement performs a distinct action, with no compressed multi-action lines. Reading flow: Initialization followed by argument and return annotation retrieval forms a natural sequence. The multiline return-annotation condition slightly interrupts flow, and inconsistent naming conventions reduce polish.
Run 3
Code Structure: A small class logically groups signature extraction and annotation access, though unused imports add clutter. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Docstrings clearly describe behavior, but validateAddress and validateAccount misleadingly suggest validation rather than annotation retrieval; nextNode and status are also vague names. Code length: Compact overall, with minor repetition from local inspect imports and explicit None returns. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Initialization followed by two accessor-like methods is natural, although inconsistent naming conventions and the unnecessarily wrapped return-annotation condition slightly interrupt the flow.