Just catching up on the thread. Guido said:
Sebastian Kreft seems to have executed a search that came to the same conclusion as Anders (typeguards are one-argument functions), but he is pushing for a way to define a typeguard as a method that guards self, e.g. if query.empty(): .... I'm not sure how to address this without adopting David's idea except to propose that if self is the only argument the typeguard applies to self.
Applying a user-defined type guard to `self` strikes me as a very unusual use case — one that probably involves anti-patterns such as a base class having knowledge of its derived classes. I don't think we should accommodate this with any special handling. The proposed mechanism already handles this if you pass self as an explicit argument, as in: ```python class Foo: def is_bar(self, x: "Foo") -> TypeGuard[Bar]: return isinstance(x, Bar) def func(self): if self.is_bar(self): reveal_type(self) # Bar ``` I agree strongly with Guido that `cast` should not be overloaded for all the reasons provided. From my perspective, `cast` should be used only rarely and as a last resort. It's effectively saying "disable all type checking safety here because I know better". It's dangerous and leads to fragile code. I wouldn't want to further legitimize its use. Also, I agree that it would be inappropriate to implicitly redefine the type of the expression passed as the first argument to `cast`. That would be inconsistent, unintuitive, and result in backward compatibility problems for existing code. David said:
it's possible to trivially implement safe_cast()...
Yes, but I'll point out that you would need to reverse the parameters because the expression that is being narrowed (in your example, the `value` parameter) must be the first param of the type guard function. Guido said:
Conclusion: There are some loose ends, but I will sponsor this PEP and likely approve it after only minor updates. Eric, please use PEP number 647.
OK, thanks. I'll work on incorporating the feedback and post a new draft soon.