PEP 742: Narrowing types with TypeIs

[Daverball (David Salvisberg)]

I can agree with you on that, I would personally prefer TypeNarrower or Narrowed over TypeIs, since there is some ambiguity about type identity vs. A is a int, as in, it is some int (including subclasses), not THE int.

As for your 2nd point, If we were going to add a third type-guard-like construct I would prefer it to be this, which also guarantees safety:

Half-baked idea: `@inline_guards`

TypeGuard isn’t my favourite feature. It feels boilerplate-y to me. It puts responsibility for soundness with the user (similar to cast, but with less cultural awareness of that fact). My ideal solution for narrowing is a small fantasy I call @inline_guards. You put this decorator on top of your utility functions, wave a magic wand, and type checkers inline the implications for control flow (sort of like pyright’s ability to alias conditional expressions, but on steroids). Such a thing could po…

With TypeIs vs ForceTypeIs it becomes just as easy to accidentally use one over the other as it would be to write an incorrect type narrower in the first place, so I don’t think it’s a big enough win personally.