Thanks Eric for updating the PEP. I have some questions:
If a type guard function is implemented as an instance method or class method, the first explicit argument maps to the second parameter (after "self" or "cls").
What's the rationale behind this? AFAIK in Typescript you can write user-defined typeguards asserting about the nature of the calling object. Using
this is SomeInterface. This could be useful to narrow an object implementing a protocol.
What's the rationale for user-defined type guards to only apply in the positive case? In fact, of all the type guards listed in the motivation, only the truthy-typeguard applies only in the positive case, meaning user-defined typeguards are going to be less powerful than builtin ones.
Maybe we could make TypeGuard exhaustive by default (working on positive and negative cases) and making the type in the negative case to be
T - guarded_type. Then we could receive an optional second argument, so that the type in the negative case is:
TypeGuard[guarded_type] -> (T - guarded_type)
TypeGuard[guarded_type, negative_extra_types] -> Union[T - guarded_type, negative_extra_types]in that way you could write all the guards listed in the motivation as user-defined ones and even narrow the type further os some existing guards:
# As shown in the motivation the negative case still has type Optional[str]
def truthy_string(s: Optional[string]) -> Typeguard[str, str]:
return bool(s)
# In the negative case it will have type Union[None, Literal['']]
def truthy_string(s: Optional[string]) -> TypeGuard[str, Literal['']]: return bool(s)
To mimic the current proposal of guards only working in the positive case one could write:
def guard(t: T) -> TypeGuard[U, T]:
return ...Finally, the example
is_str_list should probably read:
if len(val) == 0:
return allow_empty
Otherwise, it will always return
True when the list is empty.