For most of its history, CPython prioritised simplicity, portability, and ease of reasoning over performance. Performance work certainly existed, and many improvements were made over the years, but they were constrained by those priorities and by the design of the interpreter itself. Performance-critical work was therefore pushed into native extensions, typically written in C or other compiled languages. That balance shaped Python’s architecture and its reputation for decades.In recent years, as CPython has been widely adopted in mission-critical systems, performance has increasingly become a limiting factor. As a result, performance is now a first-class design constraint in CPython. This shift did not happen overnight, but through sustained work across the whole system: a specialising interpreter, doing more work in the bytecode compiler instead of at runtime, fewer runtime checks, smaller and more cache-friendly objects, and new approaches to concurrency.This keynote traces the evolution of CPython performance from its early days to the present, using concrete examples to show how work has moved from runtime to compile time, how regular and predictable behaviour makes systematic optimisation possible, and how modern CPUs influence interpreter design. It also looks at the social side of performance work: design debates, community feedback, and the trade-offs between maintainability and speed.The goal is to explain how CPython became fast by design, what it cost to get there, and what this shift means for the future of Python.