PEP 724: Stricter Type Guards

The issue is changes of this nature happen very frequently today. PRs multiple times a week will change type checker/typeshed behavior on real code that leads to errors appearing/disappearing. If you complain about this kind of change then you should expect to regularly complain about changes that create incompatibilities of this severity on mypy primer.

In practice most of errors that change are considered rare enough to be acceptable. Or new behavior is decided by maintainers to be improvement without any PEP. If you look at pr history of mypy/typeshed/pyright they all have a CI check that measures change behavior on real code for some codebases. Some of those changes are bug fixes, but clear backward compatibility breaks are common experience for “advanced” enough typing. The word “advanced” is one very unclear part here. I don’t mean advanced as positive/negative just referencing less common features or areas where exact behavior is undefined today and common cases work out, but details vary by release/type checker.

As concrete example, Releases · microsoft/pyright · GitHub has weekly releases. Behavior changes are documented in weekly notes and there is backwards compatibility break where some code that created type errors before/passed type checking changed. Each week it is common today for “advanced” behaviors to be changed in backwards incompatible ways. Yesterday’s release notes even have a change that affects more code then this PEP based on primer checks and was behavior change considered internal type checker choice. My experience is upgrading type checker on large enough codebase (~30K lines of code) with high enough usage of typing features errors most of time change. I expect to add a few type ignores/adjust a couple lines most times I upgrade pyright/mypy version and am happily surprised if a new version doesn’t change some behavior. Sometimes new bug is discovered in my code, sometimes a type checker becomes more strict in a way that’s harmless for my code, sometimes I disagree but understand rule change. There was one recent change that led to many errors appearing for my codebase for a behavior I’d consider much more common then this PEP, how should passing **kwargs be type checked.

Lastly, I’m not against more stable specification. But today type specification is very incomplete today for behaviors like this so if you use features like typeguard/overload/generics/paramspecs heavily than instability is current norm. It doesn’t seem like this specific PEP should have higher backwards compatibility standard when many other changes done at same time in github issues/discussions will not go through PEP process and commonly (multiple times per month) lead to larger backward incompatibilities.

5 Likes