Huh, I guess I’ve been at this CPython contributing thing for 19 years now? Wow! But I can’t overtake Barry or Thomas.
- I can’t set the Steering Council’s agenda. All of you do!
“Shacka when the SC plate is full.”
- I care about seeing Performance work actually land. This includes speedups as well as safely transitioning to a multithreaded runtime. Neither one must block the other. We cannot abandon the existing world of Python code while doing so. This is a very long term project even if good things land quickly in the coming term. Decisions SC worthy should focus on a feasible roadmap plan of steps to get there while remaining maintainable.
- Why do I care? Performance work opens up new opportunities. Every time we dismiss performance, consider CPython good enough, or claim that Python users aren’t demanding multithreading or fast execution and are happy with the plethora of heavyweight workarounds… we’re collectively guilty of survivorship bias thinking. Users aren’t demanding it because they’ve long since given up Python and rearchitected code in other languages or spent years engineering workarounds.
- Data science and ML. Python is glue that holds so much of that world together. A common theme I hear is getting Python out of the way of their computational work getting done on specialized hardware, lowering the overall computation latency.
- Stability is key, but don’t misinterpret this to mean no-change conservative. That I am clearly not. Lets make sure the things we do support actually matter if they’re occupying our time or getting in the way of important improvements. But we should not leave people needing their code to also run on a 4-year-old release as well as today’s hanging out to dry. There’s tooling opportunity here.
- Our CPython build systems… Creaky. I support work on replacing and if possible unifying, but the proof is in the pudding here; someone has to do the work to demonstrate benefits beyond just one system. I could imagine this being accomplished without need for much SC decision PEP involvement at all.
- Type checking and static analysis? Supportive, but there appears no reason to annotate the stdlib today. We’d need to run the top few type checkers on the stdlib in our CI before that’d be wise. Unchecked annotations must be assumed to be wrong or buggy, just like untested code.
- New language syntax. Lets tread cautiously in 3.11. We’re just seeing the effects of the new parser with syntax that requires it in 3.10. This is a challenge for tooling such as refactoring tools and reformatter. Interesting things are tightening underspecified bits such as how to parse f-strings works as I believe I saw someone start to look at?
I work for Google on our Core Python internal runtime team. Thomas Wouters (SC member and candidate) is a direct teammate; we chat regularly.
I put my name in the ring with everybody else for our first round  when we adopted this governance model.
(any typos? probably. I’m still learning a new keyboard)