Source code
from __future__ import annotations
from collections import OrderedDict
from collections.abc import Iterable, Iterator, Mapping
from typing import Any, Generic, TypeVar, overload
from .compat import MutableMapping
class CaseInsensitiveDict(MutableMapping[str, _VT], Generic[_VT]):
_store: OrderedDict[str, tuple[str, _VT]]
def __init__(
self,
data: Mapping[str, _VT] | Iterable[tuple[str, _VT]] | None = None,
**kwargs: _VT,
) -> None:
self._store = OrderedDict()
if data is None:
data = {}
self.update(data, **kwargs)
def __setitem__(self, key: str, value: _VT) -> None:
self._store[key.lower()] = (key, value)
def __getitem__(self, key: str) -> _VT:
return self._store[key.lower()][1]
def __delitem__(self, key: str) -> None:
del self._store[key.lower()]
def __iter__(self) -> Iterator[str]:
return (casedkey for casedkey, _ in self._store.values())
def __len__(self) -> int:
return len(self._store)
def lower_items(self) -> Iterator[tuple[str, _VT]]:
return ((lowerkey, keyval[1]) for (lowerkey, keyval) in self._store.items())
def __eq__(self, other: object) -> bool:
if isinstance(other, Mapping):
other_dict: CaseInsensitiveDict[Any] = CaseInsensitiveDict(other)
else:
return NotImplemented
return dict(self.lower_items()) == dict(other_dict.lower_items())
def copy(self) -> CaseInsensitiveDict[_VT]:
return CaseInsensitiveDict(self._store.values())
def __repr__(self) -> str:
return str(dict(self.items()))
Run 1
The code is well-structured with clear separation of methods and consistent use of type hints, making it readable. It avoids deep nesting and keeps actions relatively granular. However, some subtle issues reduce clarity: __eq__ may return NotImplemented (which is not False) causing unexpected behavior, the comment and indentation in __eq__ are inconsistent, and lower_items uses less-readable generator syntax. The docstring-like comments are sparse and don't fully explain design choices like lowercasing keys or the internal tuple storage. Overall, intent is mostly clear but could benefit from minor refactoring for consistency and better documentation.
Run 2
The code is generally clean and organized, with a clear class structure and consistent method grouping. Type hints and the use of OrderedDict improve clarity. Methods are concise and mostly follow single-action-per-line principles. The nesting is minimal. However, readability is slightly reduced by the lack of explanatory comments for non-obvious design choices (e.g., why original casing is stored alongside lowercased keys) and some minor clutter like empty comment lines. The __eq__ method has a slightly awkward flow due to an inline import-free instantiation and an unused variable assignment. Overall, the intent is clear, but a few explanatory comments and minor refactors would improve comprehension.
Run 3
The code is mostly readable with clear type hints and class structure. Purpose of the CaseInsensitiveDict is evident. However, readability is reduced by several blank/comment-only lines that break flow, inconsistent comment style, and a vertical layout that makes the class feel sparse. Nesting is low, which is good. Clarity is strong but affected by minor ambiguity in `lower_items` and `__eq__` (unnecessary temporary variable and comment). Code length is reasonable. Action granularity is fine. Overall, a well-intentioned class but its formatting and comments don't consistently aid reading.
Run 1
Code Structure: Logically organized around standard mapping methods, with a consistent internal storage representation. Nesting: Minimal; only simple conditionals appear. Clarity of intent: The class name, method names, and key normalization make the purpose clear, but the undefined _VT type variable and lack of documentation weaken clarity. Code length: Concise, with little unnecessary logic, although excess blank lines add visual clutter. Action granularity: Each statement generally performs one action; generator expressions are compact without being overly dense. Reading flow: Methods follow a natural mapping-interface progression, though names such as keyval and casedkey and tuple indexing require some interpretation. Overall, highly readable with minor typing and formatting shortcomings.
Run 2
Code Structure: Well-organized class with small, focused mapping methods and a consistent internal representation. Nesting: Minimal; only simple conditionals, with no deep nesting. Clarity of intent: The class name, method names, and type annotations clearly communicate case-insensitive lookup while preserving original key casing. However, _VT is never defined despite importing TypeVar, and the internal tuple representation lacks explanation. Code length: Concise overall, though unused imports and excess blank lines add noise. Action granularity: Statements generally perform one action each; generator expressions remain compact and understandable. Reading flow: Methods follow a natural progression from initialization through mapping operations to equality, copying, and representation. Inconsistent whitespace and slightly opaque names such as keyval mildly disrupt readability.
Run 3
Code Structure: Logically organized into small methods implementing a mapping interface. Nesting: Very shallow, with only simple conditionals. Clarity of intent: The class name, method names, and type annotations clearly convey case-insensitive behavior, although the undefined _VT and undocumented storage tuple reduce clarity. Code length: Concise overall; unused TypeVar and overload imports and excessive blank lines add clutter. Action granularity: Each statement performs a single clear action, with compact generator expressions remaining readable. Reading flow: Methods follow a natural progression from initialization through mapping operations to equality, copying, and representation. Inconsistent whitespace and names such as keyval slightly interrupt an otherwise straightforward flow.