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.
10:00 AM Welcome, introductions
10:30 AM - Coffee break -
11:00 AM CPython without the global interpreter lock with Sam Gross
11:30 AM Reaching a Per-Interpreter GIL with Eric Snow
12:00 PM Faster CPython project: 3.12 and beyond with Mark Shannon and Guido van Rossum
12:30 PM - Lunch -
1:30 PM WebAssembly: Python in the browser and beyond with Christian Heimes
2:00 PM F-strings in the grammar with Pablo Galindo Salgado
2:30 PM Cinder Async Optimizations with Itamar Ostricher
3:00 PM - Coffee break + group photo -
3:30 PM The issue and PR backlog with Irit Katriel
4:00 PM The Path Forward For Immortal Objects with Eddie Elizondo and Eric Snow
4:30 PM Lightning talks (submit on-site)
5:00 PM - We're done -
CPython without the global interpreter lock, Sam Gross
Python's global interpreter lock (GIL) prevents multiple threads from running Python code at the same time, making it difficult to efficiently use multi-core CPUs in multi-threaded Python programs. I propose making the global interpreter lock optional in an upcoming Python release and eventually removing it. It won’t be easy to remove the GIL. It will require substantial changes to the CPython interpreter and built-in objects and modules. The changes would likely need to be adopted over multiple Python releases and require a break in the stable ABI.
I believe the tradeoffs required to remove the GIL are manageable and worthwhile. The “nogil” Python fork serves as a proof-of-concept for such a change. I’d like to discuss the trade-offs involved and possibility of integrating ideas from the “nogil” Python fork in future versions of CPython.
Reaching a Per-Interpreter GIL, Eric Snow
For the Python community, CPython's multi-core story has been murky, at best, due to the GIL. Since 2014, I've been slowly working on a solution that centers on no longer sharing the GIL between multiple interpreters in the same process. That goal is within reach for the 3.12 release.
In this talk we will look at where things are at, focusing on the biggest remaining obstacles. This includes things like the impact of stable ABI extensions (especially older ones), what to do about the allocators, and dealing with objects exposed by the C-API. Your expertise and feedback will be invaluable as we work to find the best solutions.
Faster CPython project: 3.12 and beyond, Mark Shannon and Guido van Rossum
Now that the Microsoft Faster CPython team (helped by some outside contributors!) has delivered a ~20% speedup for 3.11 (compared to 3.10), we'll let that rest during the 3.11 beta period, except for polish as needed. In the 3.12 branch we will be working on new exciting stuff.
WebAssembly: Python in the browser and beyond, Christian Heimes
Brett, Ethan Smith, and I have been working on WebAssembly support for Python 3.11. CPython main branch now compiles to WASM, runs in modern browsers, and even the test suite passes under NodeJS with any additional modifications or patches. But WASM is not just for the web. WASI and lightweight runtimes like wasmtime can run WASM code on server-side at near native code performance in a sandbox.
In my presentation I will give you a short introduction to WASM, how it can be used to run CPython in browsers, in sandboxing for edge computing, and how wasmtime-py might solve some pain points with distribution of native code extensions. Better browser and WASI integration is going to require more changes to the interpreter core and stdlib. What kind of changes would be acceptable?
F-strings in the grammar, Pablo Galindo Salgado
Let's include f-strings in the grammar! What does that mean you say? Well, it means that the CPython parser will not need to do two passes over the f-strings to parse them correctly. That's good but there are also some interesting (optional) consequences in the Python language. Should we allow arbitrary recursive f-strings? Should we allow nested quotes of the same type?
In this talk we will discuss what including f-strings in the Python Grammar means, what is the status of the project and what are the consequences of this change and we will discuss which ones are desirable for the Python language.
Cinder Async Optimizations, Itamar Ostricher
Cinder includes several async-specific optimizations that proved quite significant for Instagram Server as an async-heavy workload.
At the core of these optimizations is an extension we’ve made to the vectorcall protocol - passing an additional flag that lets the callee know whether it is (immediately) awaited. See discussion on the BPO: bpo-46965.
The most significant optimization we were able to implement using this capability is avoiding creation of multiple tasks for coroutines that could be completed synchronously when called via gather.
We are interested in contributing our optimizations to CPython, and would like to discuss the evolution of Async in Python and how such optimizations could be achieved in a world where TaskGroups may replace gather.
The issue and PR backlog, Irit Katriel
This session is to discuss our triage and PR review practices, and consider adopting new guidelines and techniques to tackle the ever growing backlog of work.
The Path Forward For Immortal Objects, Eddie Elizondo and Eric Snow
Currently, memory immutability is not guaranteed within the runtime, even for objects deemed as immutable (i.e ints, static types, etc.). The runtime can still change an object's headers (for GC objects) and reference count; even when said instances live throughout the entire runtime execution and are effectively read-only.
This talk explores the approach, tradeoffs, and challenges to achieve object immortalization as well as the guarantees that it will have during various stages of the runtime (i.e: startup, execution, shutdown).
Do I need to sign up if I’m a Python core developer?
Yes please! We have a limited space, and we want to ensure that we're able to socially distance while still meeting in person. Please register to reserve your space.
Can I sign up if I’m not a Python core developer?
Yes you can. In the past, we had quite a number of participants who were not Python core devs. Among them were maintainers and representatives from BeeWare, CircuitPython, PSF board member, PyCharm, PyPA, etc.
Will this be recorded? Can I watch the live stream?
No, there will be no recording of the language summit, and there will be no livestream available. We understand that this is a disappointment for those who are not able to travel due to current situation. However, the format of the Summit is not well suited for spectators. It is an intense interactive discussion session among all attendees. Ideas get proposed and get shot down quickly with direct feedback. We need attendees to feel comfortable sharing their thoughts, instead of making them self-censor their feedback due to an invisible crowd looking into the meeting. We understand many people are curious as to what happens during the Summit. As usual, there will be detailed blog posts reporting on the event shortly afterwards.
While the last two Language Summits were forced into virtual meetings, the feedback received from the attendees shows that they miss the interactivity of the in-person events. Given that PyCon US is finally happening as a regular conference at a physical venue, we are moving the Summit back to the real world with it. Since a hybrid event would compromise the quality of the interaction for everyone, instead we're focusing our efforts on organizing the best in-person event we can.
Do I need to be registered to PyCon to attend the language summit?
Yes. However, if you only want to attend the language summit portion, and not the rest of the conference, then we can provide you with a voucher that allows you to be registered at PyCon. This way you'll be in the system, and staff would be able to check your vaccination status per PyCon's Health and Safety Guidelines. Please let us know if you need this voucher.
Though, we do recommend that you be registered for the full PyCon . There are amazing talks and keynotes on the schedule that you wouldn't want to miss.
The PyCon US Code of Conduct applies and will be enforced.
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