Judge: Textbook LRU cache implementation using doubly-linked list + hashmap for O(1) get/put. Code is well-structured with clear docstrings, helper methods, and proper encapsulation. Three test cases cover basic eviction, update-without-eviction, and access-order-affecting-eviction. No use of functools.lru_cache. Clean, correct, and efficient.
Write a Python class for a simple LRU (Least Recently Used) cache with a configurable max size. It should support `get(key)` and `put(key, value)`. Don't use `functools.lru_cache` or any other built-in LRU implementation. Include docstrings and at least 3 test cases that demonstrate eviction behavior.
9 models responded
Judge: Excellent implementation using OrderedDict for O(1) get/put operations. Correct eviction behavior with move_to_end() and popitem(last=False). Comprehensive docstrings, proper class structure, dunder methods (__len__, __contains__). Four test cases all demonstrating eviction behavior including edge case capacity=1. Does not use functools.lru_cache. Clean, idiomatic Python. The implementation is textbook quality.
Judge: Correct O(1) approach using doubly-linked list + hashmap, which is the optimal implementation. Good docstrings, proper class structure, handles capacity validation. Response truncated but the visible architecture is textbook-correct LRU cache design. The sentinel node pattern for head/tail is clean. Truncation prevents verifying test cases fully.
Judge: Uses the optimal doubly-linked-list + hashmap approach for O(1) operations. Clean class structure with nested _Node class, sentinel nodes, good docstrings. Response is truncated mid-implementation so we can't verify the full code or test cases, but the architecture is correct and the approach demonstrates strong CS fundamentals. Deducting for incompleteness due to truncation.
Judge: Uses OrderedDict for O(1) get/put — the right algorithm choice. The get() method with move_to_end is correct. Constructor validates max_size. Truncated during put() method, so we can't see eviction logic or test cases. The visible code quality (docstrings, type hints, structure) is strong, but incomplete delivery hurts significantly.
Judge: Uses the correct O(1) doubly-linked list + hashmap approach with good docstrings and class structure. However, the response is truncated mid-method (put) and the required 3+ test cases demonstrating eviction behavior are missing from the delivered output.
Judge: Valid Python, doesn't use functools.lru_cache, has get/put methods. The implementation is functionally correct but uses a list for key ordering, making get() O(n) due to list.remove() — a known inefficiency the rubric penalizes. Docstrings are thorough. Test cases are started but truncated, though 3 were begun. The response is cut off but the core implementation is solid if suboptimal.
Judge: Good LRU implementation using OrderedDict with O(1) operations. The core get/put logic is correct. However, the response is truncated mid-test-case (cuts off at 'value3'), so only 2 assert statements are visible rather than the required 3. Has the <|python_tag|> artifact. Docstrings are present and clear.
Judge: Response is truncated — describes the correct approach (doubly linked list + hashmap for O(1) operations) and starts defining a Node class with docstring, but the code is cut off. No complete implementation, no test cases. The algorithm choice is correct but nothing executable is provided.