We’re not ready to require types for new code. But I do think we should accept work to add types, and as we do we should start to require them in the parts of the code where they are added, as a ratchet. This means that we also need to have a high amount of validation on the places that we add types.
Wrong types are worse than no types, so this is work that we’ll need to take carefully. I’m looking forward to this work finding bugs, which I very much expect. I think we’re also going to find places where our API designs just don’t play nice with the abilities of available type checkers, because they predated a lot of the recent typing work in Python and the patterns don’t align.
I think that it would even be wise to be open to breaking changes to allow for working types. Those choices will have to be made on a case-by-case basis, and we’ll have to weigh the risks, but I think we’ll find that if type checkers aren’t able to type some of our code patterns, that we should at least consider the possibility that they aren’t optimal patterns with the current state of Python, and we should find better patterns.
We’ll need to coordinate the work to add types. To figure out what the staged integration path is. And it’ll need cooperation and clear communication from trusted community members to validate the types. The fellows won’t be able to coordinate this project, so it will take someone willing and able to communicate the plan, how it should be validated, and any compromises that need to be made in the implementation, to minimize the work mergers need to do to validate that the target has been met.