On 2/9/2021 11:21 AM, Guido van Rossum wrote:
I think we have reached consensus on PEP 647 in typing-sig. We have implementations for mypy and pyright, not sure about the rest. This PEP does not affect CPython directly except for the addition of one special item (TypeGuard) to typing.py -- it would be nice to get that in the 3.10 stdlib.
I'm CC'ing python-dev here to see if there are any further comments;
As a naive possible future user of typing, I have a couple of related comments on the presentation and suggested additions with regard to the type of TypeGuard 'instances' and the meaning of type guard function returns.
"Its return type would be changed from bool to TypeGuard[List[str]]."
My first thought was "Huh? The return type *is* a bool!" Then I realized that a TypeGuard[List[str]] is a 'specified affirmative bool', a bool for which True means 'is a List[str]'. More generally, a TypeGuard[X] is a bool for which True affirmatively means that the first argument of the function is specifically an X. I mentally condensed that to 'bool subtype' and suspect that others have and will do the same, but you later reject 'subtype' because 'subtype' has a specific meaning in the typing world that does not apply here.
Suggestion 1: Rather than mere say what a TypeGuard is not, follow the quoted sentence with a statement of what it is, such as I gave above.
"Specification\n TypeGuard Type \n <paragraph>"
The first paragraph specifies that the function must be a predicate (returns bool and only bool). It leaves out that it must be a positive or affirmative predicate for which 'True' says what the first argument is, rather than what it is not. The examples meet this requirement and narrowing only for 'if' clauses implies this requirement, but ...
Suggestion 2: End the first paragraph by stating the requirement.