PyCon 2026 Typing Summit: Thu May 14, 1-5pm

Typing
1

Hello!

The Typing Summit at PyCon US 2026 is scheduled for 1-5pm, Thursday May 14, in room 201A. Hope to see many of you there! If you plan to attend, please fill out the interests survey.

– your hosts, Carl Meyer & Steven Troxler (@stroxler )

10 Likes
2

Hi Folks!

I wanted to bump this thread, I think some folks may have missed it.

We’d love to hear from you - what kinds of topics you’d like to see discussed, any suggestions from those who attended previous years, and especially anyone interested in presenting!

- Steven and Carl, your hosts

4 Likes
3

Hi typing folks -

Thanks to everyone who filled the survey and proposed talks. We now have an agenda for the summit:

  • Experiments with AI agents and Pyrefly type errors - Conner Nilsen
  • The ty implementation of constraint sets - Douglas Creager
  • Formalizing parts of Python typing in Lean - Jia Chen
  • Exploration of tensor shape types in Pyrefly - Avik Chaudhuri
  • Intersection types for Python - Jelle Zijlstra
  • PEP 827: Type Manipulation - Michael Sullivan
  • Direction of Python’s Type System - Guido van Rossum
  • Typing Council panel / Q&A

We’re looking forward to it!

– Steven and Carl

9 Likes
4

Hi everyone -

Thanks again to speakers and attendees!

I wanted to share the slides from presentations, if you were there this might be very helpful:

We are also aiming to have recordings out soon for those who couldn’t be present, stay tuned for that.

9 Likes
5

I’d love to hear some of the thoughts, especially on @guido 's topic. Consistency between checkers, and especially pragmas, often weigh on me. I’ve been thinking about pragma comments a lot too: their placement, interaction when you are trying to hint type checkers, formatters, linters, etc. on the same line(s). I have no ideas, but just annoyances.

4 Likes
6

I had to miss Guido’s talk but consistency between checkers I think is becoming a crucial pain point. As a build-front end maintainer that is introducing a new command for type checking we are forced to pick a single implementation as the out of the box for our users because otherwise the maintenance burden on allowing a choice would be too expensive for us. Some of that is maybe “self-inflicted” because just like our format command we strive to provide good out of the box setup for users.

We talked about this at PyCon but I also agree on the pragmas because between the formatters, linters and type checker hints it can lead to lengthy pragmas off to the right of a single line of code. I would love to see more of a standardized pragma block across all tools that can be placed above a block of code that applies to code until the next line of code at the same indentation level is reached. So a pragma block above a for loop for instance would apply to all the code within the for loop block and then no longer apply once the same indentation level is reached. This works as well with function and method declarations. I would find that more readable and acknowledge that there is a lot of missing details in this idea right now.

1 Like
7

TBH, this was the “killer feature” for me with pyrefly when I was looking into the modern Rust-based type checkers. It supports putting pragmas on a line by itself above the line it affects. I think I mentioned this to the ty folks, but I don’t know if any other tool has followed suit so far.

1 Like