PYTHON PROGRAMMING SERIES Module 1 Foundations of the Event-Driven Paradigm Understanding core concepts that distinguish event-driven programming from traditional procedural or linear scripts Topics Covered Activities Estimated Time 1.1 Introduction to EDP Paradigm sort, real-world analogies ~25 min 1.2 Core Components Trace event loop, write callbacks ~30 min 1.3 Practical Application Console REPL, digital clock lab ~45 min Review &amp; Assessment Knowledge check, challenge problems ~20 min 1.1 Introduction to Event-Driven Programming What Is Event-Driven Programming? Event-driven programming (EDP) is a paradigm in which execution is controlled by external events — user actions, sensor signals, messages, or system notifications — rather than a fixed top-to-bottom sequence. Key Definition An event-driven program waits idle (or performs background work) until an event occurs. It then dispatches that event to the appropriate handler, executes it, and returns to waiting. Characteristics of Event-Driven Systems Asynchronous execution: code does not run in a strict top-to-bottom order. Decoupling: event producers (sources) are separate from event consumers (handlers). Responsiveness: the system reacts instantly when an event fires. Non-blocking: waiting for one event does not freeze other parts of the program. Scalability: many event types can be handled independently and concurrently. Comparison: Procedural vs. Event-Driven Procedural / Linear Event-Driven Instructions execute top-to-bottom Execution is driven by incoming events Control flow set by the programmer Control flow set by the user or system Program finishes and exits Program loops, listening continuously Easy to trace step-by-step Requires understanding callbacks &amp; state Good for scripts and data pipelines Good for GUIs, games, servers, IoT Example: monthly payroll calculator Example: chat app responding to messages Real-World Analogies Recognise event-driven systems in everyday life before writing code: Analogy Event Handler / Response Smartphone User taps the screen Open the tapped app Traffic light Timer or sensor fires Change light colour Fire alarm Smoke detector triggers Sound siren, unlock exits Customer service Phone rings Agent picks up and responds Email inbox New message arrives Show notification + badge Discussion Prompt 💬 Think of three more real-world event-driven systems you interact with daily. For each one identify: (a) the event source, (b) the event, and (c) the handler. Share and discuss your examples with a partner before moving on. 🧪 Activity 1.1A — Paradigm Sort Time: 10 minutes | Type: Individual or pair Instructions: Read each scenario. Label it Procedural (P) or Event-Driven (E). Write one sentence explaining your choice. Scenarios: 1. [ ___ ] A script reads a CSV file, calculates totals, and writes results to a new file. 2. [ ___ ] A web server waits for HTTP requests and responds to each one independently. 3. [ ___ ] A program reads student grades from top to bottom and prints each grade. 4. [ ___ ] A game character moves left whenever the player presses the left arrow key. 5. [ ___ ] A temperature logger records sensor readings every 5 minutes automatically. 6. [ ___ ] A button in a mobile app shows a menu when tapped by the user. Answer Key: P, E, P, E, P, E 1.2 Core Components of Event-Driven Systems Events An event is any occurrence the program can detect and respond to. Events fall into five categories: User input: keyboard presses, mouse clicks, touch gestures, form submissions. System: timer expirations, file-system changes, OS signals, memory alerts. Network: incoming socket data, HTTP responses, WebSocket messages. Hardware/sensor: GPIO pin changes, temperature thresholds, motion detection. Application: custom events raised by your own code (e.g., &apos;orderPlaced&apos;). The Event Loop The event loop is the central dispatcher. It continuously polls for new events and routes each one to its registered handler. A simplified pseudo-loop: # Simplified Event Loop (pseudo-code) event_queue = [] while True: # 1. Loop forever if event_queue: # 2. Are there pending events? event = event_queue.pop(0) # 3. Dequeue the next event handler = registry[event] # 4. Look up the registered handler handler(event) # 5. Execute it else: wait_for_event() # 6. Sleep until something arrives Python&apos;s asyncio Event Loop asyncio.get_event_loop().run_forever() enters the loop. Coroutines (async def) are tasks scheduled on the loop. I/O events (sockets, files) use OS-level selectors under the hood. You will explore asyncio in depth in Module 4. Callbacks and Handlers A callback (also called a handler) is a function registered to execute when a specific event fires. # Basic callback pattern def on_key_press(key): &quot;&quot;&quot;Handler: called whenever a key-press event fires.&quot;&quot;&quot; print(f&quot;Key pressed: {key}&quot;) # Register with an imaginary event system: event_system.on(&apos;key_press&apos;, on_key_press) # When user presses &apos;a&apos;, the system calls: # on_key_press(&apos;a&apos;) --&gt; Key pressed: a Three Ways to Define Callbacks in Python Named function: def on_click(event): ... — most readable; use for complex logic. Lambda: event_sys.on(&apos;click&apos;, lambda e: print(e)) — for simple one-liners. Method: event_sys.on(&apos;click&apos;, self.handle_click) — for object-oriented designs. 🧪 Activity 1.2A — Trace the Event Loop Time: 15 minutes | Type: Individual, then group review Read the code below. For each label (A–H) write what happens at that step. import time handlers = {} # (A) handler registry def register(event_name, fn): # (B) handlers[event_name] = fn def dispatch(event_name, data=None): # (C) if event_name in handlers: handlers[event_name](data) def on_tick(data): # (D) print(f&quot;Tick! Data: {data}&quot;) register(&apos;tick&apos;, on_tick) # (E) for i in range(5): # (F) dispatch(&apos;tick&apos;, data=i) # (G) time.sleep(1) # (H) # What happens at this step? (wr