Steering Council Nomination: Savannah Ostrowski (2026 term)

Core Development Steering Council Nominations
2

Thank you so much for the nomination, Pablo, and hey folks, I’m excited to run for a seat on this coming term’s Steering Council!

About Me

I’m a CPython core developer and the Release Manager for Python 3.16 and 3.17. My contributions to CPython have largely centered around performance work as part of the broader Faster CPython team, particularly the JIT. I’m a co-author on PEP 744 (JIT Compilation) and the author of PEP 774 (Removing LLVM requirement for JIT builds). I’m also the PEP 11 platform contact for 64-bit Raspberry Pi and contribute a buildbot for that platform. I’ve also been known to help out where help is needed, in areas like the argparse module.

I’m also actively engaged in the broader Python community, having previously served on the Jupyter Foundation Governing Board, where I was elected inaugural Board Treasurer and helped establish community proposal funding and budget processes. I’ve served on program committees for both PyCon US 2025 and JupyterCon 2025, and gave the opening keynote at EuroPython 2025, covering overcoming the barriers to CPython contribution.

In the last decade, I’ve held both engineering and dev tools product management jobs. I call out the latter specifically because I believe this background gives me complementary skills in systems thinking, stakeholder coordination, and translating between technical constraints and user needs. These are skills that are directly relevant to Steering Council work.

Affiliations

Outside of CPython, I work as a Software Engineer at FastAPI Labs, where I work on FastAPI Cloud and other open source projects in the Python ecosystem. I am fortunate to have my employer support my CPython work as part of my role, with dedicated time carved out for core development and my upcoming role as release manager.

What I Care About

A faster Python that works for everyone. Performance is fundamental to Python’s future as it is one of the levers that determines whether Python remains competitive for emerging workloads, whether we can support the next generation of AI/ML applications, and whether developers can build responsive, efficient systems without rewriting in other languages. We’re at a critical inflection point with multiple performance initiatives converging: the JIT, free-threading, etc. I want to ensure these pieces come together in the right way, that we make technically sound decisions while keeping the experience smooth for Python’s diverse user base.

Making technical decisions more accessible. The PEP process, while valuable, has become intimidating. I’ve experienced this firsthand and I’ve watched others hesitate to propose changes because the process feels overwhelming. What was designed to document decisions has evolved into a pretty heavyweight, often exhausting process. I think we need to re-examine how we delegate technical decisions and when different levels of process are appropriate. Not every change needs a full PEP with extended discussion. And when PEPs are necessary, contributors should have clearer guidance on expectations, timelines, and decision-making authority. This is an area where the Steering Council can help: creating frameworks that make decision-making clearer, more predictable, and less intimidating for everyone involved. Good process should enable work, not obstruct it, and I’d like to bring that perspective to these conversations.

Growing the contributor base. I understand what it’s like to be newer to the project. That recent memory is valuable for making CPython more welcoming and accessible to contributors, and for identifying barriers we’ve normalized but shouldn’t accept. One challenge I’ve observed is that decisions often happen across discuss.python.org and GitHub without clear documentation of what was decided and why. This makes it difficult for newcomers to understand context or learn from past discussions. But this is just one barrier among many. I’d love to see a working group actively focused on contributor experience: examining how we communicate decisions, how we can make the pathway from contributor to triager to core team member more accessible, what role mentorship could play, and identifying other obstacles we’ve stopped noticing. Growing and diversifying our contributor base deserves dedicated, ongoing attention.

What I’ll bring to the SC

I am deeply committed to Python. Serving on the Steering Council (or even as Release Manager) isn’t something that I’m seeking out as a resume line. It’s work that I genuinely care about and will dedicate significant time to.

I bring a fresh perspective while respecting what works. Being newer to the project means that I can help identify barriers and inefficiencies that longer-tenured core developers may have normalized. At the same time, I deeply respect the processes that have made Python successful for decades. My goal isn’t to disrupt for the sake of change, but I do want us to evolve based on both new observations and established wisdom.

I’ve worked in areas that needed attention. My contributions to CPython have largely been in areas with few to no other active core developers - the JIT compiler and argparse. I have worked to get those areas into much better maintained states. I understand what it’s like to be responsible for code that matters to many users but has few active maintainers, and I bring that perspective to thinking about project sustainability.

I value Python’s user experience. Every decision we make affects millions of developers. With my background in product management, I’m hardwired to constantly think about our user experience. I hope to bring that focus and attention to our users to each Steering Council discussion.

Selected Contributions

  • LLVM upgrades: Maintained Python’s JIT compiler infrastructure through multiple LLVM version upgrades (16→18→19→20→21), including implementing x86-64 trampolines to handle memory addressing constraints and resolving platform-specific compilation issues across architectures.

  • macOS multi-arch JIT support: Enabled JIT compilation for universal binaries on macOS, allowing Python 3.14 to ship optimized builds that work seamlessly across both Intel and Apple Silicon architectures.

  • JIT performance optimizations: Implemented optimizations using pure op machinery for constant comparisons and instruction sequences, contributing to overall JIT compiler efficiency.

  • argparse user experience improvements: Enhanced the developer experience with features like the suggest_on_error functionality that helps users catch typos and mistakes more easily, along with documentation improvements and bug fixes to make command-line argument parsing more intuitive.

In closing, I want to congratulate Barry, Donghee, Emily, Greg, and Pablo on their 2025 term and thank them for their service to our team and to the Python community.

Thank you for considering my nomination!

Online Presence

44 Likes