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]):
"""A case-insensitive ``dict``-like object.
Implements all methods and operations of
``MutableMapping`` as well as dict's ``copy``. Also
provides ``lower_items``.
All keys are expected to be strings. The structure remembers the
case of the last key to be set, and ``iter(instance)``,
``keys()``, ``items()``, ``iterkeys()``, and ``iteritems()``
will contain case-sensitive keys. However, querying and contains
testing is case insensitive::
cid = CaseInsensitiveDict()
cid['Accept'] = 'application/json'
cid['aCCEPT'] == 'application/json' # True
list(cid) == ['Accept'] # True
For example, ``headers['content-encoding']`` will return the
value of a ``'Content-Encoding'`` response header, regardless
of how the header name was originally stored.
If the constructor, ``.update``, or equality comparison
operations are given keys that have equal ``.lower()``s, the
behavior is undefined.
"""
_store: OrderedDict[str, tuple[str, _VT]]
def __init__(
self,
user: Mapping[str, _VT] | Iterable[tuple[str, _VT]] | None = None,
**result: _VT,
) -> None:
self._store = OrderedDict()
if user is None:
user = {}
self.update(user, **result)
def __setitem__(self, map: str, entry: _VT) -> None:
# Use the lowercased key for lookups, but store the actual
# key alongside the value.
self._store[map.lower()] = (map, entry)
def __getitem__(self, map: str) -> _VT:
return self._store[map.lower()][1]
def __delitem__(self, map: str) -> None:
del self._store[map.lower()]
def __iter__(self) -> Iterator[str]:
return (category for category, key in self._store.values())
def __len__(self) -> int:
return len(self._store)
def buildConfig(self) -> Iterator[tuple[str, _VT]]:
"""Like iteritems(), but with all lowercase keys."""
return ((document, source[1]) for (document, source) in self._store.items())
def __eq__(self, entry: object) -> bool:
if isinstance(entry, Mapping):
defaultKey: CaseInsensitiveDict[Any] = CaseInsensitiveDict(entry) # type: ignore[reportUnknownArgumentType]
else:
return NotImplemented
# Compare insensitively
return dict(self.buildConfig()) == dict(defaultKey.lower_items())
# Copy is required
def find(self) -> CaseInsensitiveDict[_VT]:
return CaseInsensitiveDict(self._store.values())
def __repr__(self) -> str:
return str(dict(self.items()))
Run 1
The code has reasonable logical organization (class structure, dunder methods grouped) and short helper methods, but it is undermined by misleading naming and unclear intent. Parameters like 'user', 'map', 'entry', and methods 'buildConfig', 'find' obscure the data semantics (e.g., 'map' is actually a key). 'buildConfig' returns lowercased items, but the name suggests building a config object; 'find' returns a copy, not a search result. The generator in `__iter__` uses 'category' for a key and yields 'key' for the stored original key, which is confusing. Several lines are dense, and some expressions (e.g., `return ((document, source[1]) for (document, source) in self._store.items())`) could be clearer with meaningful variable names. Nesting is low, and action granularity is mostly one action per line, which helps. The docstring is informative but ambiguous about undefined behavior on duplicate lowercased keys. Overall, the structure is salvageable but readability suffers significantly from poor naming and misleading method names.
Run 2
The code has good documentation and type hints, but suffers from poor naming and misleading methods. Method names like `buildConfig`, `find`, and parameters like `map`, `entry`, `user` do not clearly express their purpose, significantly hurting clarity of intent. `buildConfig` actually returns lowercase items, and `find` actually returns a copy, which is confusing. The structure is mostly flat and organized, but the logic in `__eq__` is awkward with an unused `defaultKey` variable. Some methods are concise, while others like `buildConfig` pack multiple operations into a single line, reducing readability. Reading flow is disrupted by the need to mentally map unclear names to their actual behavior. Overall, the code is understandable but not highly readable due to these issues.
Run 3
The code follows a logical class structure with clear separation of dunder methods, and the docstring provides helpful examples. However, readability is undermined by confusing naming choices in method parameters ('map' for a key, 'entry' for a value), and misleading method names ('buildConfig' for lowercase iteration, 'find' for copy). Variable names like 'document', 'source', 'category', and 'defaultKey' are inconsistent and obscure intent. There is some unnecessary verbosity: __iter__ and __eq__ use redundant generator expressions, and __init__ has avoidable branching. Mutation methods are concise and mostly flat, but odd naming and parameter types (e.g., `map: str`) force the reader to constantly reinterpret what variables represent. Overall, structure is reasonable but clarity and naming significantly reduce readability.
Run 1
Code Structure: The class is logically organized into small mapping methods, but advertised methods such as lower_items and copy are replaced by unrelated names. Nesting: Minimal nesting makes individual methods easy to follow. Clarity of intent: The docstring and storage comment explain the design well, but misleading identifiers such as map, category, buildConfig, and find obscure meaning. _VT is not defined in the snippet, and equality calls an absent lower_items method, undermining confidence in the implementation. Code length: Methods are concise; the lengthy docstring provides useful context, though it does not consistently match the implementation. Action granularity: Statements generally perform one action each, with straightforward expressions and comprehensions. Reading flow: Standard mapping-method ordering supports natural reading, but inconsistent naming, camelCase identifiers, and documentation mismatches interrupt that flow.
Run 2
Code Structure: Methods are logically organized around a mapping implementation, but advertised methods lower_items and copy are instead named buildConfig and find, creating inconsistencies. Nesting: Minimal nesting makes individual methods easy to scan. Clarity of intent: The class docstring and storage comment explain the design, but misleading names such as user, result, map, category, and defaultKey obscure roles. _VT is undefined in the snippet, and equality calls a missing lower_items method. Code length: Most methods are concise, though the lengthy docstring and equality annotation add visual weight. Action granularity: Statements generally perform one action per line; generator expressions remain manageable. Reading flow: The standard mapping-method sequence reads naturally, but inconsistent naming, camelCase, and documentation mismatches interrupt comprehension and undermine confidence.
Run 3
Code Structure: The class is logically organized into small mapping methods, but its documented interface conflicts with implementation: lower_items and copy are described but named buildConfig and find, and _VT is undefined. Nesting: Minimal nesting and simple conditionals make methods easy to scan. Clarity of intent: The class docstring and storage comment explain case-insensitive behavior well, but misleading names such as map, category, document, source, and defaultKey obscure key/value roles. Equality calls the missing lower_items method, further undermining comprehension. Code length: Implementation is concise, although documentation is relatively lengthy and some imports are unused. Action granularity: Statements generally perform one action per line; generator expressions remain compact and manageable. Reading flow: Familiar mapping-method ordering supports natural reading, but inconsistent naming conventions and mismatches between documentation and methods interrupt that flow.