[Python-Dev] Re: [EXTERNAL] PEP 647 Accepted
On 4/10/2021 1:02 PM, Guido van Rossum wrote: I propose that we just clarify this in the docs we'll write for TypeGuard. I agree. When I reviewed the PEP, my concern was not with 'TypeGuard' itself, once I understood more or less what it means, but with the explanation in the PEP. -- Terry Jan Reedy ___ 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/NSFP5LWAV4XEYRLXRDQJ2PHEQBKIPWDL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [EXTERNAL] PEP 647 Accepted
I propose that we just clarify this in the docs we'll write for TypeGuard.
On Sat, Apr 10, 2021 at 8:33 AM Eric Traut wrote:
> Hi Barry,
>
>
>
> Thanks for the note. Apologies for the slow reply — your email got trapped
> in Microsoft’s spam filters, and I just noticed it.
>
>
>
> The idea of using a wrapper type was my first thought too. In fact, I
> implemented that solution in prototype form. It was disliked by almost
> everyone who tried to use the feature. The wrapper approach also got a
> negative reaction on the typing-sig when I posted the initial proto-spec. A
> wrapper prevents some common use cases (e.g. filter functions) and was
> found to be cumbersome and confusing.
>
>
>
> I understand your concern about the fact that type guards return bools but
> this is not reflected in the return type. This was debated at length in the
> typing-sig, and we considered various alternatives. In the end, we weren’t
> able to come up with anything better. I’m somewhat comfited by the fact
> that TypeScript’s formulation of this feature (which was the inspiration
> for the idea and is generally a well-liked feature in that language) also
> does not directly mention “boolean” in its return type annotation. Here’s
> an example of the syntax in TypeScript:
>
>
>
> ```
>
> function isNone(type: Type): type is NoneType {
>
> return type.category === TypeCategory.None;
>
> }
>
> ```
>
>
>
> -Eric
>
>
>
>
>
> On 4/6/21, 1:31 PM, "Barry Warsaw" wrote:
>
> 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)
>
>
>
>
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-Dev] Re: [EXTERNAL] PEP 647 Accepted
Hi Barry,
Thanks for the note. Apologies for the slow reply — your email got trapped in
Microsoft’s spam filters, and I just noticed it.
The idea of using a wrapper type was my first thought too. In fact, I
implemented that solution in prototype form. It was disliked by almost everyone
who tried to use the feature. The wrapper approach also got a negative reaction
on the typing-sig when I posted the initial proto-spec. A wrapper prevents some
common use cases (e.g. filter functions) and was found to be cumbersome and
confusing.
I understand your concern about the fact that type guards return bools but this
is not reflected in the return type. This was debated at length in the
typing-sig, and we considered various alternatives. In the end, we weren’t able
to come up with anything better. I’m somewhat comfited by the fact that
TypeScript’s formulation of this feature (which was the inspiration for the
idea and is generally a well-liked feature in that language) also does not
directly mention “boolean” in its return type annotation. Here’s an example of
the syntax in TypeScript:
```
function isNone(type: Type): type is NoneType {
return type.category === TypeCategory.None;
}
```
-Eric
On 4/6/21, 1:31 PM, "Barry Warsaw" wrote:
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)
___
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/LEXTUSWQOIH7P2XZ3OVXFAIIQC6NWX2E/
Code of Conduct: http://python.org/psf/codeofconduct/
