Hi Eric, I am trying my hand at implementing TypeGuard for mypy. Writing test cases made me wonder what exactly should happen if the type of the argument passed is already subtype of the type in the TypeGuard expression. For example: ``` def is_nonzero(x: object) -> TypeGuard[float]: return isinstance(x, float) and x != 0 def main(x: int): if is_nonzero(x): reveal_type(x) # int or float? ``` Should this *widen* the type of x from int to float? Or should it keep the narrower type int? If we inlined the condition it would keep int, but the way I understand the PEP, it ignores the original type and forces the type in the TypeGuard, in order to support the is_str_list() example. The PEP does not seem to answer my question directly, since it is mainly concerned with the relationship between the two types in the function definition (arguing convincingly that it should not be a strictly narrowing relationship). I think we had all assumed that the same thing applied to the type of the actual parameter, but having constructed this example I'm not so sure. Pyright currently reveals float. --Guido On Sun, Dec 27, 2020 at 10:49 AM Guido van Rossum <guido@python.org> wrote:
Thanks!
I think it's ready for the next stage, actually submitting a PR for the peps repo. Once that passes tests I will merge it, at which point we should update the Post-history header. (I have a few nits that are best handled in the PR stage.)
May 2021 be an improvement over 2020,
--Guido
On Sun, Dec 27, 2020 at 10:02 AM Eric Traut <eric@traut.com> wrote:
I hope everyone's having an enjoyable, relaxing, and healthy holiday season!
I've updated the [draft PEP]( https://github.com/erictraut/peps/blob/master/pep-0647.rst) to incorporate the feedback.
* I updated the PEP number and added Guido as the sponsor. * Sebastian was interested in more examples of a multi-parameter type guard functions, so I added a second example (`is_set_of`, which also demonstrates that type guard functions can be generic). * I added more details in the "rejected ideas" section about a decorator-based syntax that was considered but abandoned. * I added an extensive justification in the "rejected ideas" section for why I don't think we should enforce any strict narrowing requirements, including the looser form that Guido proposed. Guido, if you disagree with my reasoning here, let's discuss further. * I added text in the "rejected ideas" section explaining why we decided not to support the narrowing of arbitrary parameters and always assume the first parameter is the value being narrowed. I mention in this section that we could extend the PEP in the future if this becomes important. * I added text in the "rejected ideas" section explaining why we are not providing any special mechanism for narrowing the implied "self" or "cls" parameters in instance/class methods.
-Eric -- Eric Traut Contributor to Pyright and Pylance Microsoft Corp. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: guido@python.org
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>