On 12/23/20 12:48 PM, Eric Traut wrote:
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.
(The example of safe_cast() I provided doesn't actually use TypeGuard so I'm assuming you meant cast(), whose definition is already fixed by the existing API to have a typing form as the first parameter.)
Ah yes. It would be necessary to use explicit syntax in TypeGuard to declare which (non-first) parameter was involved. Here's a corrected definition of cast() that uses TypeGuard:
``` def cast(form: TypeForm[T], value: object) -> TypeGuard[value=T]: return value ```
On 12/23/20 4:48 PM, Sebastian Kreft wrote:
[...] Alternatively, we could allow type guards as instance/class methods but assume that the first implicit parameter (`self` or `cls`) is the value being tested.I like your last proposal, having `self` or `cls` the value being tested.
This also makes sense to me.
Although it does seem unusual to have a TypeGuard instance method that redefines self/cls. Would it be narrowing the type of self/cls? To what end? I'd like to think of a realistic example here...
On 12/23/20 4:48 PM, Sebastian Kreft wrote:
I don't think that multiple arguments is the problem here. I've come across a couple of cases in real code where I wouldn't have been able to use the TypeGuard mechanism if it was limited to just one argument, so I'm reluctant to place that limitation on it.Note that it'd be just a deferral until we get more insights on how typeguards are used in Python. Then we could extend TypeGuard to accept an optional second argument specifying which argument is the one being guarded, something like TypeGuard[T, 'second'].
I'll still advocate for a future syntax more like `TypeGuard[second=T]` if the ability to explicitly label the applicable parameter appears later. :)
To stress an earlier point, I do *not* think it's necessary to add that kind of parameter-labeling syntax in the initial PEP, especially given that for most uses of TypeGuard (ignoring combinations with TypeForm) it's always the *first* parameter of the function that's being narrowed, which doesn't require the labeling syntax. (If keyword arguments inside [] were already available, I'd have a different opinion.)
Best, -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy