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)