Answer A: Anthropic Claude Opus 4.6
class InMemoryDB: def __init__(self): self._main_store = {} self._transaction_stack = [] def get(self, key): # Search from the most recent transaction backwards for txn in reversed(self._transaction_stack): if key in txn: return txn[key] return self._main_store.get(key, None) def set(self, key, value): if self._transaction_stack: self._transaction_stack[-1][key] = value else: self._main_store[key] = value def begin(self): self._transaction_stack.append({}) def commit(self):...
Show Full Answer ▼
class InMemoryDB: def __init__(self): self._main_store = {} self._transaction_stack = [] def get(self, key): # Search from the most recent transaction backwards for txn in reversed(self._transaction_stack): if key in txn: return txn[key] return self._main_store.get(key, None) def set(self, key, value): if self._transaction_stack: self._transaction_stack[-1][key] = value else: self._main_store[key] = value def begin(self): self._transaction_stack.append({}) def commit(self): if not self._transaction_stack: raise Exception("No active transaction to commit") changes = self._transaction_stack.pop() if self._transaction_stack: # Merge into parent transaction self._transaction_stack[-1].update(changes) else: # Merge into main store self._main_store.update(changes) def rollback(self): if not self._transaction_stack: raise Exception("No active transaction to rollback") self._transaction_stack.pop() # Example usage if __name__ == "__main__": db = InMemoryDB() # No transaction print(db.get("a")) # Expected: None db.set("a", 10) print(db.get("a")) # Expected: 10 # Transaction db.begin() db.set("a", 20) print(db.get("a")) # Expected: 20 # Nested transaction db.begin() db.set("a", 30) print(db.get("a")) # Expected: 30 # Rollback nested db.rollback() print(db.get("a")) # Expected: 20 # Commit outer db.commit() print(db.get("a")) # Expected: 20 # Error cases try: db.commit() # No transaction active except Exception as e: print(f"Error: {e}")
Result
Winning Votes
0 / 3
Average Score
Total Score
Overall Comments
Answer A is a correct and well-structured implementation of the InMemoryDB class. It uses a stack-based approach with clear variable naming (_main_store, _transaction_stack). The logic for get, set, begin, commit, and rollback is all correct and handles nested transactions properly. It raises a generic Exception for error cases, which is functional but less semantically precise than using RuntimeError or ValueError. The example usage is included and matches the expected output. Overall a solid solution with minor stylistic shortcomings.
View Score Details ▼
Correctness
Weight 35%Answer A correctly implements all methods. The get method searches the transaction stack in reverse order before falling back to the main store. The set method writes to the current transaction or main store as appropriate. Commit merges changes upward correctly. Rollback discards the current transaction. All nested transaction scenarios are handled correctly.
Completeness
Weight 20%Answer A implements all five required methods (get, set, begin, commit, rollback) and includes the full example usage from the task prompt. Error cases are handled. No missing functionality.
Code Quality
Weight 20%Answer A uses clear variable names and a logical structure. However, it raises a generic Exception for error cases rather than a more specific exception type like RuntimeError or ValueError, which is a minor code quality issue. The code is otherwise clean and readable.
Practical Value
Weight 15%Answer A is practically useful as a reference implementation. The example usage demonstrates all key scenarios. The generic Exception is a minor practical concern since callers may want to catch specific exception types.
Instruction Following
Weight 10%Answer A follows all instructions: implements the required class and all five methods, handles nested transactions, raises errors for commit/rollback without active transactions, and includes the example usage from the prompt.
Total Score
Overall Comments
Implements the required API with a clear transaction stack and correct nested begin/commit/rollback behavior for simple set/get semantics. The logic of resolving keys from the latest transaction to the main store is sound. Minor issues are mainly around robustness and polish: it raises a generic Exception type, and there is no explicit guidance or handling for deletion semantics (not required) or for distinguishing an explicitly set None from missing (not required but sometimes relevant).
View Score Details ▼
Correctness
Weight 35%Correctly supports nested begin/commit/rollback via a stack of dicts; get searches from inner to outer; commit merges into parent or main store; rollback discards current changes. No functional errors for the specified operations.
Completeness
Weight 20%Implements all required methods and includes example usage demonstrating nested transactions and error case. Does not address optional behaviors like deletes (not requested).
Code Quality
Weight 20%Readable and straightforward, with clear member names; slight drawback is generic Exception usage and minor extra verbosity (explicit None default in get).
Practical Value
Weight 15%Practical for basic transactional KV usage; lacks extras like custom exception types, deletion markers, or transaction introspection, but those are beyond the prompt.
Instruction Following
Weight 10%Follows the requested interface and behavior, including nested transactions and raising an error when committing/rolling back without an active transaction.
Total Score
Overall Comments
Answer A provides a fully correct and functional implementation of the in-memory database. The logic for handling nested transactions is sound, and the code is clean and readable, with particularly descriptive variable names like `_transaction_stack`. Its main weakness is the use of the generic `Exception` for error handling, which is generally discouraged in favor of more specific exception types.
View Score Details ▼
Correctness
Weight 35%The implementation is fully correct. The logic for `get`, `set`, `commit`, and `rollback` correctly handles nested transactions by searching through the transaction stack in the correct order and merging/discarding changes appropriately.
Completeness
Weight 20%The answer is complete, implementing all five required methods: `get`, `set`, `begin`, `commit`, and `rollback`.
Code Quality
Weight 20%The code is clean and readable. The variable names, especially `_transaction_stack`, are very descriptive. The only minor drawback is the use of the generic `Exception` class for error handling.
Practical Value
Weight 15%The solution provides a good, clear implementation of a common data structure pattern. It's a valuable educational example, though it lacks features like concurrency control for production use.
Instruction Following
Weight 10%The answer perfectly follows all instructions. It implements the specified class and methods, handles the logic as described, and includes the example usage block.