The Python Language Summit is an event for the developers of Python implementations (CPython, PyPy, Jython, and so on) to share information, discuss our shared problems, and — hopefully — solve them.
These issues might be related to the language itself, the standard library, the development process, status of Python 3.10 (or plans for 3.11), the documentation, packaging, the website, et cetera. The Summit focuses on discussions and consensus-seeking, more than on merely presentations.
PyCon’s Code of Conduct applies and will be enforced.
08:00 AM Welcome, Introductions, Guidelines
08:30 AM: PEP 654 - Exception Groups and except*, Irit Katriel, Yury Selivanov and Guido van Rossum
09:00 AM: Progress on running multiple Python interpreters in parallel in the same process, Victor Stinner & Dong-hee Na
09:30 AM: short break (15 minutes)
09:45 AM: CPython improvements at Instagram, Dino Viehland
10:15 AM: Making CPython faster, Guido van Rossum
10:45 AM: long break (30 minutes)
11:15 AM: HPy: Present & Future, Antonio Cuni
11:45 PM: Lightning Talks (pre-selected)
12:15 PM: End of Day 1. See you tomorrow!
1:00 PM Welcome back + Re-introductions
1:15 PM: Challenges packaging Python for a Linux distro, Matthias Klose
1:45 PM: The Python Documentation WG, Mariatta Wijaya & Carol Willing
2:15 PM: short break (15 minutes)
2:30 PM: What _is_ the stdlib?, Brett Cannon
3:00 PM: What Should I Work on as a Core Dev?, Eric Snow
3:30 PM: long break (30 minutes)
4:00 PM: Fuzzing and Testing Python with Properties, Zac Hatfield-Dodds
4:30 PM: Lightning Talks / sign-up during the summit
5:00 PM: End of Day 2. It's a wrap!
PEP 654 - Exception Groups and except*, Irit Katriel, Yury Selivanov and Guido van Rossum
The authors of "PEP 654 - Exception Groups and except*" will discuss the current state of work on the problem of raising and handling multiple unrelated exceptions simultaneously.
Progress on running multiple Python interpreters in parallel in the same process, Victor Stinner & Dong-hee Na
More or more companies are looking for solutions to run multiple Python instances in the same process to scale their workload on all CPUs. Most of the non-controversial work has been done, let's discuss the remaining controversial part :-)
CPython improvements at Instagram, Dino Viehland
We'll give an overview of the changes that we've explored within CPython at Instagram, the results of those improvements, and the things we're continuing to explore. We'll have open sourced Instagram's fork of CPython (Cinder) ahead of PyCon so the code will be available. There's some substantial changes to be discussed including:
- A new JIT
- A new inline caching framework for the interpreter
- Eager async evaluation
- Static Python
- Dictionary watchers
- A number of small changes and enhancements across the code base
The goal is to give a high level introduction to the work and to increase collaboration in the performance space and help avoid duplication of efforts.
Making CPython faster, Guido van Rossum
We'd like to make CPython faster. We could go about this in different ways -- we'll discuss our plans and ideas looking for feedback.
HPy: Present & Future, Antonio Cuni
We all know that the C API is problematic: it makes the life very hard for alternative implementations and it hinders CPython's ability to refactor/innovate some of its internals.
As presented last year, the goal of HPy is to design a better C API, together with a reasonable way to migrate the existing ecosystem. In the talk I'll present HPy and how CPython could help to make it easier to adopt.
Challenges packaging Python for a Linux distro, Matthias Klose
Distributing Python for Linux, and how to keep the distribution users (who are not necessarily developers) as well as Python developers unharmed. Point out issues with current approaches, present and discuss improvements.
The Python Documentation WG, Mariatta Wijaya & Carol Willing
The CPython Documentation Work Group has been formed, and we want to kick start the work. We’ll share some updates on how this works, and what to expect from the workgroup. We want to hear feedback or questions from core devs and the community about this workgroup.
What _is_ the stdlib?, Brett Cannon
If you were asked to describe what the stdlib was in a sentence, could you say anything beyond "a collection of modules that the Python core team decided were important at some point"? How about what the future of the stdlib is other than "🤷♀️"? This talk is meant to spark a conversation to try and answer these sorts of questions more clearly. There will be no predetermined suggestions of the size the stdlib should be, nor acceptance criteria for the future. This is about sparking thoughts on the topic of the stdlib so we can eventually have a PEP that outlines our goals and the purpose of the stdlib.
What Should I Work on as a Core Dev?, Eric Snow
Historically the core team hasn't been organized around any sort of roadmap (Py3k aside). This makes sense for a group of volunteers. One consequence is that usually there isn't a lot of clarity on what efforts by any one of us will have the most positive impact. Mostly we're left up to our own interests and awareness. While the steering council is working on a bit more direction, we should also consider getting dedicated PM resources to help. They wouldn't tell us what to do but rather curate a list of the projects/tasks that would benefit the community the most. Would that help? Would you use such a resource? Let's discuss.
Fuzzing and Testing Python with Properties, Zac Hatfield-Dodds
CPython's current testing strategy misses bugs - but all is not lost! Property-based testing is both *powerful* and *practical*: with the same or less effort, you can write tests that find more bugs. Of course you can keep using traditional tests where that makes sense, but **it's time to adopt property-based testing in CPython CI**.
Some core developers already use Hypothesis, but can't check in those tests - and there have already been regressions that would have caught. Just in the last year, Hypothesis has found bugs in the PEG parser (including a segfault in beta1, and error-handling issue 42218 in 3.9.0) and Zoneinfo module development; and there are many more tests ready to merge. Even better, Google now supports Python code in OSS-Fuzz for continuous fuzzing - so we could have an ongoing search and find issues like the buffer overflow in CVE-2021-3177 earlier.
If you have any questions, the Core Development section of our Discourse instance is the best place to ask. For private/sensitive communication, write to mariatta at python dot org and/or lukasz at python dot org