# LANGUAGE SUMMIT 2022

[Schedule](https://us.pycon.org/2022/events/language-summit/#schedule)

"PyConUS" Wifi password: pyconslc2022

## CPython without the global interpreter lock with Sam Gross

* Now based on 3.9.10
* Proposal: compile-time configure flag that compiles python without the GIL.
* Previously considered a run-time flag, but now a compile-time flag is favored due to complexity, ABI stability and risk
* Doesn't see a way to make GIL-less without ABI changes
* This would mean that you would need to build extensions for both the Gil and GIL-less version
* Why not continue as a fork?
* Coordination of the ecosystem. If it was a fork, only extensions that cared about the fork would have no-gil support.
* Differences in performance will lead to different idiomatic Python in the fork vs vanilla CPython
* Next step: Reach agreement in principle to remove the GIL, or not
* How do we reach decision?

### Questions

***Barry**: What kind of changes would be required of extensions to support?*
* Some, like Scikit none.
* Cython: one file and 15 switches?
* NumPy: 15 lines or so
* Changes are to things like choosing build flags,threaded code.
* Pure python code is unaffected

***Itamar**: Enough interest from scientific libraries to build extensions?*
* Yes

***Larry**: What are the changes to the Python API?*
* Small changes, would make sense to return functions like pydict
* expose the locking APIs
* expose the

***Samuel Colvin**: Is a runtime flag more complex?*
Code complexity is similar, but ABI stability is a big issue and risk in adopting big changes

***Carl Meyer**: Update on single thread performance*
No benchmark yet. Main branch has been much faster since Oct. Guess 5-10% depending on CPU if thread-safety code is removed from the changes.

***Guido**: If we agree to compile time flag, won't that add a lot of churn, LoC and complexity in the core CPython codebase?*

* Core devs will have to think of what they've written in terms of thread safety.
* LOC is not a good metric, about 25_000 LoC changed but much is generated files (For comparison, 3.9.4=>3.9.5 has more LOC changes)
* Main changes are in the allocator

***Pablo**: Need to consider maintenance cost and ensuring no behavior changes. Lay out not just the plan, but also the downsides.*

***Carol**: From the scientific community, reproducibility is key. How to best communicate the packages/distribution of libraries for gil vs no-gil. Everything in scientific community would need to be identifiable as gil or nogil. Would it be easier to fork it? It is easier to say to use PyPy or CPython.*
Not sure yet how to address this.

* (Carol) BinderHub: Reproducibility needs to be there for all packages. If you're running it agains diff versions of CPython, they all need to be tested. An end users need to be directed at the proper build for their enviroment.
* Lets talk offline

***Mark**: Is the register/accumulator VM required?*
Not required but useful.

Code has implicit reliance on GIL.

* Example: Specializer: It modifies code depending on what is determined at runtime. If modifying the code happens in one thread and the code is executed in another, that may depend on the GIL.
* For non-Python code which allocates the GIL to protect usage of non-python code, these would have to be recoded to do their own locking.

* Current benchmark 25% slower (older version of the code)

***Ned**: As Carol said, there is a lot of coordination to be done on the release side? Adds a lot of complexity.*

* Certainly adds complexity and cost but thinks that we can get bogged down if we have to make all decisions about this before deciding whether it's important or not.

* (Ned) Might make sense to think small to start with
* (Thomas):
* Would agree that compile time flag is preferable.
* CI load will double regardless
* Echoes Mark Shannon's comment that user code is going to be a huge difficulty.
* (Sam) It typically was fairly quick to fix these problems, only a day or at most two.

(Thomas) How long would it take you to identify there is thread-related bug/?
-> pretty quickly? a lot!

***Mattias**: Two things:

* Timeline, when do you add the new option/revert it if necessary? because downstreams have to build and test their work (linux distros, anaconda, etc)
* Can also change the ABI name (and possibly interpreter name)

**Carol**: Go to Scipy in Austin in July, where maintainers of scientific Python are. Ask them? Is the scientific world is the most benefit from?
It's what I'm interested most.

***Christian**: Memory guards (CPU Cache, etc).*
* (Sam) For memory guards: use the C primitives that are re-entrant.
* (Sam) As mentioned previously, most user code is no-GIL-safe by accident, its only a few places that tend to be the problem
* (Sam) For the compatibility of extensions which are written to use the gil as a one-and-done lock, they will just need to be re-written otherwise you don't get the performance benefits that are the whole point of this.

## Reaching a Per-Interpreter GIL with Eric Snow

Slides: https://bit.ly/37LMQ6K

* [PEP 554](https://peps.python.org/554) & [PEP 684](https://peps.python.org/684)
* Core developer since 2012
* Been working on per-interpreter gil since 2014(?)

* Multiple interpreters in single process (1997, Python 1.5)
* PyInterpreterState added in 1997

* As of 2017, still had several thousand global variables.
* Added PyRuntimeState struct and started moving globals in there
* Wrote a tool to identify globals
* Down to around 1200 remaining globals

* Interpreter Isolation: Only mostly mostly isolated.
* The GIL is a big piece of shared state
* Per-interpreter GIL is to help this

* Biggest Obstacles:
* Allocators
* custom allocators are stored in globals
* make per-interprer? but non trivial change
* GIL just for the allocators?
* Switch to thread-safe allocators?

* Potential burden to extension module maintainers
* users will clamor for support, maintainers wll feel pressure to provide support
* How can Python Core help

* Must deal with 250 objects exposed by c-api
* must continue to expose each
* One option: Make all objects immortal (PEP 684)
* Or, make all objects per-interpreter

### Questions

***Larry**: what is the benefit of having multiple subinterpreters per process if they can't share objects?*

* Running using multiprocessing module, there is overhead. On some platforms, maybe less; on Windows more substantial.

* With multiple interpreters in the process, yes it isn't useful.

* We would also want to add new means to (pass objects? communicate?) safely between subinterpreters

* (Larry): is this more for optimization?
* Yes, better performance.

***Guido**: certain apps that embed Python can't use multiprocessing as easily as multi-interpreters?*

(Sam) Yes

***Pablo**: We allow people to substitute the allocator right now at any time which makes it difficult for us to evaluate.*

tracemalloc, for instance can change the allocator on the fly. (See Thomas's response)

* (Cristian) You have to set the allocator before

Thomas: tracemalloc is on top of the regular allocator, so it's protected

Eric Snow:

***Larry**: The prev talk is about removing Gil. You're talking about continuing Gil. If we remove the GIL, how will it affect you?*

It won't make much difference. I anticipate small change

These are good changes in and of themselves. (Removing globals, making code re-entrant).

***Christian**:

***Pablo**: The behaviour of GIL-manipulating API needs to be defined. Currently, code will crash but fixing it requires deciding what the right behaviour is.

## Faster CPython project: 3.12 and beyond with Mark Shannon ~~and Guido van Rossum~~

It's just Mark because Guido is ~~too busy live-tweeting~~ "delegating to Mark".
Might not be too controversial, so we can go for early lunch

We aim to be data driven; hard to know where to direct our efforts
- Easy to measure how long it takes currently but hard to estimate how long it should take

We need your help: we need more benchmarks
* A benchmark is just a program that is self contained and reasonably deterministic that we can time

Some ideas:
- Complete [PEP 659](https://peps.python.org/659) (Dynamic specializing)
- for loops
- binary operations
- Memory consumption for 3.11 is almost same as 3.10
- want to reduce the memory used by CPython structures
- Fewer ref counting operations,
- Lower gc collector overhead

C extensions
- If we didn't use C extensions, we could just use PyPy and speed things up that way
- Higher-level and lower-level interfaces for C extensions

JIT: everybody wants it
- Probably no until 3.13, can start developing the tech for it
- Initially implement a trace interpreter (Good for testing of concepts which is what we need initially)

Parallelism
- **Status quo**: Easiest, but no improvement in perf
- **Nogil**: most work. it can be done
- Many current optimizations assume the GIL exists
- **Multiple interprerters**: smaller performance impact

Other things
- Lazy import support
- [PEP 523](https://peps.python.org/523) replacement (e.g. [PEP 669](https://peps.python.org/669) for debuggers)
- Better VM support for Numba, JAX, etc. and greenlets

### Questions

How do we handle platform-specific code?
- Specializing interpreter offers a baseline speedup, while JIT is an extra

Brandt Re: JAX JIT and Pytorch JIT, have we reached out to those folks yet?
- No, not yet
- What these tools compile looks like Python but is really DSLs
- Need to find a good handover point
- Declarative API for tools to interact with CPython core

How does this compare to other optimization strategies?
- Not going to help highly tuned C code
- Pure Python code benefits from specilization
- Other cases depend on the specific operations

## WebAssembly: Python in the browser and beyond with Christian Heimes

[Slides](https://speakerdeck.com/tiran/language-summit-2022-webassembly-python-in-the-browser-and-beyond)

* web assembly is "machine independent machine code" supported by browsers
* Designed to be both portable and fast
* emscripten and wasi are two different layers on top of web assembly that give a posix-like environment for compiling to web assembly.
* Improving python building to cross compile to web assembly with emscripten (--with-emscripten-target=browser)

- webassembly binary abi is very strict
- [bpo-40280](https://github.com/python/cpython/issues/84461)

mystery project -> go watch keynote

Benefits of adding this as an official target:
- We can run Python anywhere incl Android iOS app development
- pygame
- Trey Hunner's pastebin
- jupyter binder
- We could try adding a wasm engine to cpython and then packaging extensions could compile to wasm (to theoretically run anywhere)

Question?
(who?) all web assembly are 32 bit?
yes, at the moment, because browsers won't give you more than 4GB of memory. There is a 64 bit spec in the works

Matthias: Would we be introducing a 32 bit tier 1 target after moving to removing all of them?
we still have support for 32 bit for windows.

What's the startup time?
Loading the actual binaries: 5MB, 3MB stdlibs

Senthil: W

Web assembly Repl https://repl.ethanhs.me/

Ned: for PyGame, which gui toolkit?
WebGL.
Ned: not tk?
No

Samuel:
pyiode doesnt have urllib,

Christian: What is the statement on what platform support?

Pablo: When we say we support these platforms,
Gotta be careful in the definition of "support"
In general code using sockets or processes don't currently work.

Senthil: If Python supports web assembly, what do we get?
We need people who have knowledge we dont have inside in core team. Need expertise in front web.

Keynote by Peter Wang, go watch it

Ned: distutils, how close that we can say "we dont need distutils"
4 modules: ctypes, curses, window, readline which have special cases which we don't fully understand (old platform support)
Is this feasible for 3.11?
This makes Pablo nervous?
3.12 is more reasonable

## F-strings in the grammar with Pablo Galindo Salgado

The parser sees f-string just as string
f"foo" is a string

f" {1 $" is also a string

grammar:
* Only tells us that there is a string.
Figuring out that it's an f-string goes through 1400 lines of C code for parsing string

Parsing code is complicated

you have an f string pass it to parser, the complicated c code ???

What we say in the doc about f-string grammar, is right but also high level and not helping when other python implementation wants it. it has tokenizer

Proposal: to introduce a bunch of rules in the grammar to teach the grammar and parser to understand how fstrings work
also need tokenizer changes

change tokenizer to allow two modes: normal and fstring
tokenizer to keep a stack of modes
change the grammar to include the fstrings
change the tokenizer
fix a bazillion of errors
remove handwritten parsing code
write a pep
profit

why:
easier maintenance
grammar will be more complete
better error msgs in fstrings
new lines will be possible
easier ast building

Exciting possibilities:
- f"{"foo"}" right now is impossible, will be valid code
- How many levels of nested fstrings
- should we allow backslashes?
- what about tools parsing it?
- are we going to break black again?

Questions:
Eric V Smith:

* reason why it wasn't done, was for external tools (easy to just add "f" as a character that starts a literal string. Allowing external tools to parse it easier.
* Same reason for backslash.
* I'm all for this, but lets limit to two levels as we can relax it later if it turns out to be requested.

What about nested quotes?

In [4]: f"""a{f'''b{f"c{f'd {1+2=}'}"}'''}"""
Out[4]: 'abcd 1+2=3'

Eric: Eric spoke with people writing editors of Python at Pycon Cleveland and nobody objected about this at all.
People were more surprised that it doesnt work.

Guido: I'm all for it. Tools that handle multiple languages already have to handle it (e.g bash)

* Parsing f-string is inefficient right now
* Error is reported after the whole file has been parsed

Eric Snow:

Mark: We should allow newlines. (meaning, an actual 0x0a byte in the middle of an fstring's expression) because it's the same as a parenthesized expression.

Thomas: we are all in agreement. You should just do it.
Lukasz: You can spend the next 10 minutes implementing it.

## Cinder Async Optimizations with Itamar Ostricher

Cinder includes several async specific optimizations
let the cllee
when a corou is detected,

able to avoid creation of coroutie objects
implement taskless gathers,
5% improvement in instagram efficiiency

Taskless Gather:
elide the creation of tasks and scheduling them to the event loop for awaitables that execute eagerly without suspending

Benchmark: submitted to pyperformance PR 187
called async_tree

comparison cpython and cinder, but the benchmark does not isolate async specific optimizations.

We would like to upstream the optimizations
but it's not as straightforward.
Controversies:
- issue with Fairness (the order that coroutines are run, and how often once they await)
- evolution of async in Python , task groups

Task groups is much needed improvements, but is not clear how the await-aware calls optimizations would apply to task groups.

Path forward to bring to CPython?
Compatibility with Taskgroups?

Adopt await-aware protocol
extend taskgroups API

Question:

Carol: not sure how to avoid creation of tasks if it was eagerly executed

Mark: Created 1000 tasks in one request. Do you mean coroutine, or conceptual Task?
With creating `Gather`, which creates `Tasks`
Can you pick apart
gather is a huge part of it. 4%
to rewrite Gather in C

Guido wants to have a dialogue about this

* Fairness change is probably not a blocker for this
Task group API, I could see having a flag
Not sure how often people are using tasks or not.
We dont know because it was just added in 3.11 alpha
need to talk with Trio team
Taskgroup.create_task to be replaced with an API called enqueue (which enqueues the coroutine instead of creating the task)

Pablo: vectorcall
Thomas: vectorcall function is global

Should we have Larry talk about the Beautiful Third Option?

## Impromptu talk: Larry Hastings

Annotations:
posted in python-dev few days ago.
separate threads
been working in secret
lots of ideas were given on python-dev
Final idea: solve circular references and forward references of Classes of annotations that refer to another one <!-- delete? , it becomes circular, but if you import inside the code, it's ok. -->

Annotation is problematic.

First attempt:
Second [PEP 563](https://peps.python.org/563) (like pydantic or Hypothesis)
[PEP 649](https://peps.python.org/649) fixes a lot of problems, but not all

See Larry's note at the end of this file about dataclass

This has not been uniformly warm-received.
I do think this would solve forward and circular references.

Questions:

Guido: would be less unfriendly if yo didnt change the grammar. you impemented uisng two decorators.

I used decorator

## The issue and PR backlog with Irit Katriel

Noisy monitors - Sam Schillace
a large pile of old, low rpirity bugs obscures newer quality issues and overall drift of theprodc

its far better to resolve something into the right bucket or "will not fix"
to keep the tool clean.

It's better to let the contributor that we wont fix it, instead of silence.

Exmaple
2002 requested API to acces tkinter lock.

7 years later" should we close it?
core dev: why close it's valid.

2010: ping!
coredev: no need to close because no one responded.

2022- migrated to gh-26387

Suggestion: instead of "why close it" -> Why leave it open?
Will someone implement api to tkunter lock just because of 20 year old issue.

We often jump into: "what should the bot do?". But let's focus on the principles.
There is a cost to having a lot of noise.

We have the stale bot. But it gets ignored and remain stale.
Now what? It's just stale.

What's ths stale about? Who are we talking to? Are we talking to the pR author, or pr reviewer.
It's mixed.
the bot doesn't know.

Suggestion: Add an "accepted" label:
-means: I understand, and can reproduce the isuse.
- i agree that this should be fixed.

stale ping only goes to OPs of unaccepted issues.

Questions:

Ned: let's acknowledge the incredible job Irit is doing. Thank you.
On the second suggestin, it sounds good in theory.
Sometimes it's also about no core dev wants to take ownership.
By adding the accepted, what does it mean. Who owns it now?

Irit: Would you close an issue because nobody is maintaining it?

Irit: there may be value in the issue even if nobody can fix it now.

Carol: the semantics. "Accepted" means we'll do it. "Acknowledged" means we've seen it and not ignoring it.

If we don't have somebody to maintain it, lacks expertise, add a label?

Jelle: in this example the 20 yo. tkinter: it's just not going to happen.
Should we just close it?

Irit: we probably can't do it automaically by bot, but we can do this manually.

Jelle: agree, not automatic.

Toshio: the tkinter seems to be accepted but nobody has done it. Is this a workflow issue? It's ok to still work on it and reference the closed issue?

Senthil: Other large communities have similar problems. Let the bot close unless core dev says different.

Irit: but this is the problem: we start by talking about what the bot should do.

Carol: Speaking from someone who maintains a large project outside of python: Often such label needs to be added manually. Bots just won't be able to do it.
We need to identify next steps clearly: ie. finding who can review it.
Triaging really needs real people who has the understanding.
And I agree there is cognitive overload in keeping open issues,

In jupyter we would close issues.

Basicall say "give me the reason to keep this open."

Guido: if someone says I want this open, then keep it open.

Pablo: When you mark as wontfix, the OP will start demanding explanation from maintainers. Have had to start ghosting because can't always have time to provide explanation. And people don't always like it.

Sometimes it's easier to keep it open just because as maintainer we don't have to spend the time to explain and say no.

Zac: Maintainer time: there are sufficient volunteers for things core devs like to do, but not for issue triage. I find it useful to distinguish between issues where I'd accept a PR, vs issues where I will volunteer to work on it. If nobody is volunteering to work on it, I'd close after 2-3 years to save volunteer time. Important to respond to PRs quickly though.

Lukasz: PR and Issue are different. PR people has worked on it. For issues that has open discussions, there is less urgency to close it.

Toshio: We should just open new issues (?)
Does having more committers solve this? By creating PRs it would show that they can contribute

Itamar: it's confusing as a non core dev - is this an issue where a PR would be accepted if I wrote one? Does a core dev want to work on it?

Thomas: we want to hve the mney to be able to hire more commiters. Lukasz has been working hard to address PR backlog and get the numbers down. Tried for two weeks; merged about 100 and closed 40 more PRs, and PR numbers still went up after that time.

Ned: The lack of uniformity on how us core devs treat issues/prs.
tkinter has been ownerless for a long time. need to agree on a policy on how we all going to work.

Christian: have a contributor implement the change that I want. but have adesign first ahead before implementing.

## The Path Forward For Immortal Objects with Eddie Elizondo and Eric Snow

What does it mean to achieve immortality?

Avoid mutations

Motivation:

Mitigation:
Making all interned strings immortal
- tradeoffs:

pyframe_clear is costly.
remove the decref and at the same time specia;oze decref
get some improvements in performance, but also tradeoffs
slight memory increase

saturated incref
not backward compatible

Discussion:

what's an acceptable regression to pave way for language evolution? WHat's a reasonable path to upstream.

Mark: Saturating with the signed check. Have you any idea of what if we combine these two?
About 1% improvement?

Sam Gross: saturating incref?

Mark: It's going to break c-extensions etc? How do we all feel about that? Maintainability issue.

No it will not break extensions but (?)

Pablo: motivation is a lot of potential future work, but what are the gains?
are we ever going to be able to cross the line? eg numpy will count references now so changing those semantics will break them.

unlikely we can sacrifice backwards compatibility

Sam:

(?who):

Thomas: Don't think it's possible while keeping stable ABI.

For instance, PY_None could be INCREF'd every time a function returns and that would overflow if the function is called enough.

Eric: assuming we resolve the oter issues, at what point are we ok ?

Thomas: Speaking for myself, wasn't expecting the number to be this low (1-2%), I think it's acceptable. but the tradeoff is it worth.

???

You want it because you get extra bits?

Is it crazy to keep pursuing this? Or what?

Thomas: always against 32 bit refcount in 64 bit system. In this design, .... it's reasonable to say 32 bit is enough.

Pablo: Speaking for myself, .... think we don't care about 2%

## LIGHTNING TALKS

### lazy imports (and how they work in Cinder) - Carl

Import doesnt happen until imported object is referenced
transparent: nothing observable change

Why bother:
- a given invocation of a program uses only a small % of it simport
- CLI with any subcommands

results at Meta: see 70% startup time imprv
40% memomry improvement
eliminates almost all import cycles

Why is this harD:
imported object mmust be represned yy a deferred object placeholder
but must never leak andbe visible

First try didn't work
modify implementation of every load opcode for defered object
still have leaks

Second try:
where do all imported objets live, and must alwas beloaded from?
a dictionary! alrady have lookup fyc=ncitions
just add lookdict_unicode_deferred
set it when a deffrerd object is added
checks any fecthed vlalues and rrsolved before returneing

Success: fast, no leak and comprehensive

HOw is it enabeld
per module via from __fiture import lazy_imports
better globally with -x lazy_import

Downsides:
importerror can be raised anywhere from rndom code
if not careful, codebase might implicit;y start to require it (and cant disbale it because of import cycles)

import side effect become even less predicable
can force a particular import to be eager by redesigningit

Upstreaming: solve a lot of problems for Python users.
Implementation is weird and invasive, dictionaries triggering imports

Could it ever be the default behavior? or must always be opt-in

Credit to German Mendez Bravo who did the implementation. he'll be at thes sprints.

Question from Thomas: ???

Mark:

### python-dev@ or discuss.python.org as authoritative communication - Thomas ~and/or Pablo~

Thomas and Pablo are oth SC

SC are agreeing that discourse to be authoritative.
Voting has to come to discourrse
SC thinking of changing this requirement, and want to give you heads up.
that we won't require you to subscribe to pyyhon-dev. Discourse will be the authoritative and default.

### Asks from Pyston - Kevin Modzelewski

The state of python benchmarking and pyperformance

Guido:

Zac: for hypothesis, I don't care how many frames I have remaining, but do care that I can set it to whatever exact number remaining [to avoid flaky tests](https://github.com/HypothesisWorks/hypothesis/pull/2506)

### Fields vs. methods & a new character in identifiers? - Samuel Colvin ["presentation" link](https://gist.github.com/samuelcolvin/aae8eec5c145de73e8781a26cf56b533)

We've seen all the problems

### Core Development and the PSF - Thomas

Sponsorship has been redesigned
Google providing Lukasz first year as CPythn dev in residence
Meta is providing the second year
Will spend on a second core dev
May want to hire non-core dev as CPython dev in residence

## Larry's presentation

#x.py
B = ForwardClass(metaclass=Meta)  # Calls Meta.__class_size__()???

@dataclass
class A:
  value: B

#x_impl.py
from x import B

@dataclass
@forward(B)  # ?? Too late, can't pass B to the metaclass as __forward__=B
class B(base, metaclass=Meta):  # Add __forward__=B here instead
  value: A

Questions:

Eric v smith: the `continue` class

Pablo: in theory, because all cycles have to go through annotations, can'y we just do another cycle

Guido: Technicall this can work.
But how do we get the B from forward class?

Christian: use a similar mechanism as future import for the forward class?
from `__forward_class__` import B

Irit: the name continue, does it work?
Cannot continue more than once.
Can you declare the class and add later on?
No. Both new and `__init_subclass__` want to examine the ocontent of the class and both are done before init, before allocating the object. we need to delay the construction of the object until uch later.

Samuel: can you change what B is?
You can do it anyway now

Brandt: what's the issue of making the forward class becoming weakref?
That was the second proposal. called class proxy object.

Guido: All static typing people are happy with pep 563, but only if it is default. If pep 563 is not default, then it does not help them static typing people.

If we have good solution, we wouldn't delay it for 2 releases already.

Pablo: We don't understand all the problems that need solving.

(see brett's thread on Discuss)

Samuel: