On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith <greg@krypto.org> wrote:
TL;DR of my TL;DR - Not conveying bool-ness directly in the return annotation is my only complaint.  A BoolTypeGuard spelling would alleviate that. 

This is exactly my feeling as well. In fact, I do not understand why it cannot simply be a parameterized Bool. That would avoid all confusion. Yes, it's not the technical jargon type system designers use... But the existing proposal moves all the mental effort to non-experts who may never use type checking tools.

I.e. if I read this:

def is_str_list(v: List[Any]) -> Bool[List[str]]:

I just think, "OK, it returns a bool, and those mypy people are doing something else funny that I don't need to worry about." If I see TypeGuard[...whatever..] I automatically think "that's a weird thing I don't understand, but it looks like it returns a boolean when I read the body."

FWIW, this hypothetical non-expert is me. I've actually gotten in the habit of using simply type annotations in most of the code I write (a lot of which is for teaching). But I never actually check using type checkers. It's quite likely some of my annotations are not actually sound, but to me they are documentation. I.e. I'll use an annotation of str/list/float, but not precisely parameterized types, union, generics, etc.