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]:
Um, that's not a valid type guard according to Eric's PEP. The type guard function must return a bool. Or is this part of an alternate proposal where that's not the case? Maybe you could add some more context?
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
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.)
I agree that with PEP 637 syntax this would look nicer. However it wouldn't work in Python versions before 3.10, so maybe we could offer Sebastian's suggestion as a backwards compatible syntax option (like for variadics we're leaning towards `*Ts` in 3.10 with `Expand[Ts]` for earlier versions).