The Python Steering Council reviewed PEP 647 -- User-Defined Type Guards, and is happy to accept the PEP for Python 3.10. Congratulations Eric!
We have one concern about the semantics of the PEP however. In a sense, the
PEP subverts the meaning of the return type defined in the signature of the
type guard, to express an attribute of the type guard function. Meaning, type
guard functions actually *do* return bools, but this is not reflected in the
return type:
"Using this new mechanism, the is_str_list function in the above example would
be modified slightly. Its return type would be changed from bool to
TypeGuard[List[str]]. This promises not merely that the return value is
boolean, but that a true indicates the input to the function was of the
specified type.”
In fact, the promise that it returns a bool is de-facto knowledge you must have
when you see “TypeGuard” in the return type. It is an implicit assumption.
Generally this might not be a problem, however when a type guard function is
used for multiple purposes (e.g. a type guard and a “regular” function), then
the return type is misleading, since a TypeGuard object is *not* returned.
It’s unclear what type checkers would do in this case.
The SC debated alternatives, including the decorator syntax specifically
mentioned in the Rejected Ideas. We also discussed making TypeGuard a
“wrapping” type defining an __bool__() so that e.g. is_str_list() would be
defined as such:
def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
"""Determines whether all objects in the list are strings"""
return TypeGuard(all(isinstance(x, str) for x in val))
but this also isn’t quite accurate, and we were concerned that this might be
highly inconvenient in practice. In a sense, the type guard-ness of the
function is an attribute about the function, not about the parameters or return
type, but there is no way to currently express that using Python or type
checking syntax.
I am not sure whether you considered and rejected this option, but if so,
perhaps you could add some language to the Rejected Ideas about it. Ultimately
we couldn’t come up with anything better, so we decided that the PEP as it
stands solves the problem in a practical manner, and that this is for the most
part a wart that users will just have to learn and internalize.
Cheers,
-Barry (on behalf of the Python Steering Council)
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2ME6F6YUVKHOQYKSHTVQQU5WD4CVAZU4/ Code of Conduct: http://python.org/psf/codeofconduct/
