The Blog
A quiet corner of the internet for essays, engineering notes, and the occasional book. Read at your own pace.
Python encourages us to write code that is explicit, readable, and simple. Exceptions are part of its everyday idiom, yet a function's signature rarely tells us which failures it may raise. When invalid input is an expected part of the job, that leaves an important part of the function's behavior outside its declared type.
In Part 1 we went looking for the roots. We saw the concurrency crisis that made threads feel too heavy, watched the industry move scheduling up the stack into an event loop, and then rebuilt that loop ourselves out of nothing but Python generators
For years, we’ve been told that `async-await` is a triumph of language design: a clean, elegant syntax sugar that gives us high-performance, non-blocking I/O without the headache of nested callbacks. But look closer at any mature codebase, and you’ll find a different story.
Errors are not exceptional. A config file that does not exist, JSON that does not parse, a missing key: these are ordinary outcomes your program should expect. Yet Python's default tool for them, the exception, treats every error as a surprise that interrupts control flow and travels invisibly up the call stack.