Exercise 1: Adding remove_item() to the MVC Example — Possible Solution
====================================================================

THE NEW MODEL AND CONTROLLER METHODS
------------------------------
    class TodoModel:
        # ...existing __init__/add_item unchanged...
        def remove_item(self, text):
            self.items.remove(text)

    class TodoController:
        # ...existing __init__/handle_add unchanged...
        def handle_remove(self, text):
            self.model.remove_item(text)

Both follow this chapter's own add_item()/handle_add() shape exactly -
the Controller still does nothing but forward the request to the
Model.

VERIFYING view.render() REFLECTS THE REMOVAL
------------------------------
    after two adds: Todo list: Buy milk, Walk the dog
    after remove (no changes to TodoView at all): Todo list: Walk the dog

TodoView's own source was not touched at all for this exercise -
render() still just reads self.model.items, exactly as this chapter
wrote it. The removal shows up correctly because render() reads the
model's CURRENT state every time it's called, not a snapshot taken at
some earlier point.

WHY THIS CONFIRMS MVC'S OWN CHARACTERISTIC BEHAVIOR
------------------------------
This is the direct, positive side of this chapter's own MVC finding -
the same "the View reads live state directly" property that requires
no mediator to keep MVC's View in sync also means NO NEW VIEW CODE IS
EVER NEEDED just because the Model grew a new operation. Contrast this
with Exercise 2's own MVP version, where a new Presenter method was
required specifically to keep the View correctly informed.

WHY THIS WORKS AS AN ANSWER
------------------------------
The new methods mirror this chapter's own established add_item()/
handle_add() pattern exactly, the View is confirmed unmodified, and the
resulting render() output is verified directly rather than only
asserted to reflect the removal.