[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

FWIW after reviewing the feedback on the PEP, I think now that we should proceed with the original proposal and submit it to the Steering Council's tracker (https://github.com/python/steering-council/issues) for their review. Eric, what do you think? --Guido On Tue, Feb 9, 2021 at 8:21 AM

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Eric Traut wrote: """It must be possible to express the type guard within the function signature. In other words, the implementation should not need to be present. This is important for compatibility with type stubs and to guarantee consistent behaviors between type checkers.""" Can type

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Another advantage of annotating the variable is that it moves some stuff out the signature line. def is_str_list(val: List[object]) -> TypeGuard[List[str]]: is probably OK on length, but if there were even a second typed and defaulted parameter, it would start to get unwieldy. And if the

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

> Could you summarize your proposal in a few lines? Use PEP 593 `Annotated` the way Adrian has proposed, but with an additional parameter which maps the type guard on the given function parameter name: ```python def check_int_and_str(x, y) -> Annotated[bool, TypeGuard(int, "x"), TypeGuard(str,

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Could you summarize your proposal in a few lines? I've tried to read that email several times now and I still don't follow the proposal. You can leave the reasoning *why* you believe your proposal is better out -- I just want to see what it will look like (how to define a type guard, and how to

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

I've proposed PEP 593 `Annotated` too, but in the typing-sig mailing list: https://mail.python.org/archives/list/typing-...@python.org/message/CVLLRWU7MU7T2AMC4P7ZEG4IMJF6V5UL/ and Guido had the following answer: > I see PEP 593 as a verbose solution to the problem "how do we use annotations for

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

FWIW, it would really be nice if this was called IsInstance[...]; I feel like that would neatly encapsulate its meaning to both old and new, that it's just a yes/no on whether this is an instance of [...]. TypeScript has the concept of a type guard but doesn't use that name in code, so there's no

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sun, Feb 14, 2021, 5:34 PM Guido van Rossum wrote: > But note that 'bool' in Python is not subclassable. > Sure. But that's why I suggested 'Bool' rather than 'bool'. It's a different spelling, but one with a really obvious connection. > > I.e. if I read this: >> >> def is_str_list(v:

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

That pattern is used almost as much as multi-argument guards. I checked the typings from DefinitelyTyped (JS equivalent of typeshed) and found the following statistics: 7501 packages 100 (1.3%) packages defining type guards 13 (0.17%) packages defining multi-argument type guards 10 (0.13%)

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On 2/14/21 2:34 PM, Guido van Rossum wrote: On Sun, Feb 14, 2021 at 12:51 PM David Mertz > wrote: On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith mailto:g...@krypto.org>> wrote: *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sun, Feb 14, 2021 at 12:51 PM David Mertz wrote: > On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith 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

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sun, Feb 14, 2021 at 11:49 AM Gregory P. Smith 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. I'm +0.3 now. Otherwise I elaborate on other guarding > options and note a few

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith 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

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

(there's a small TL;DR towards the end of my reply if you want to read in reverse to follow my thought process from possible conclusions to how i got there - please don't reply without reading the whole thing first) *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return annotation

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

I'm a +1 on using Annotated in this manner. Guido mentioned that it was intended for only third-parties though. I'd like to know more about why this isn't a good pattern for use by Python libraries.  On Sun, 2021-02-14 at 16:29 +0100, Adrian Freund wrote: > Here's another suggestion: > > PEP 593

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Here's another suggestion: PEP 593 introduced the `Annotated` type annotation. This could be used to annotate a TypeGuard like this: `def is_str_list(val: List[object]) -> Annotated[bool, TypeGuard(List[str])]` Note that I used ( ) instead of [ ] for the TypeGuard, as it is no longer a type.

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sat, Feb 13, 2021 at 07:48:10PM -, Eric Traut wrote: > I think it's a reasonable criticism that it's not obvious that a > function annotated with a return type of `TypeGuard[x]` should return > a bool. [...] > As Guido said, it's something that a developer can easily > look up if they

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On 14/02/21 8:48 am, Eric Traut wrote: def is_str_list(val: Constrains[List[object]:List[str]) -> bool: ... Maybe something like this? def is_str_list(val: List[str] if True else List[object]) -> bool: ... -- Greg ___ Python-Dev mailing

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Hello, On Sat, 13 Feb 2021 19:48:10 - "Eric Traut" wrote: [] > Paul said: > >...to work around deficiencies in the current generation of Python > >typecheckers > > It sounds like you're implying that this functionality will be no > longer needed at some point in the future when type

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

I think it's a reasonable criticism that it's not obvious that a function annotated with a return type of `TypeGuard[x]` should return a bool. That said, the idea of a user-defined type guard comes from TypeScript, where the syntax is described

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sat, 13 Feb 2021 at 17:33, Guido van Rossum wrote: > On Sat, Feb 13, 2021 at 2:38 AM Paul Moore wrote: >> >> I have to agree here. I'm not a frequent user of type hints yet, but I >> am starting to have to maintain code that has type hints, and from a >> maintenance perspective, I have to say

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

> On Sat, 13 Feb 2021 at 07:11, Steven D'Aprano wrote: > > Without reading the PEP, how is anyone supposed to know that this > > returns a bool? > By looking at the name, or at the return statements in the body. These are expected to be really short. Tooling can certainly easily be taught what

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sat, 13 Feb 2021 at 07:11, Steven D'Aprano wrote: > > On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote: > > > It impairs readability, because it muddles the return type. > > The function in the example returns a bool. > > The annotation is also misleading as the annotation is on

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Hello, On Sat, 13 Feb 2021 18:08:30 +1100 Steven D'Aprano wrote: > On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote: > > > It impairs readability, because it muddles the return type. > > The function in the example returns a bool. > > The annotation is also misleading as the

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote: > It impairs readability, because it muddles the return type. > The function in the example returns a bool. > The annotation is also misleading as the annotation is on the return > type, not on the parameter that is narrowed. > > At

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

My primary reaction seems similar to Mark Shannon's. When I see this code: def is_str_list(val: List[object]) -> TypeGuard[List[str]]: ... I cannot tell what it returns. There is no readable indication in that this returns a boolean so the reader cannot immediately see how to use the

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Fri, Feb 12, 2021 at 12:14 PM Jim J. Jewett wrote: > Current PEP 647 draft says: > > "Some built-in type guards provide narrowing for both positive and > negative tests (in both the if and else clauses)" > > Should there be a separate (sub-?) type for those TypeGuards that *do* > allow

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Current PEP 647 draft says: "Some built-in type guards provide narrowing for both positive and negative tests (in both the if and else clauses)" Should there be a separate (sub-?) type for those TypeGuards that *do* allow narrowing even on a False? Leaving it as an implementation detail

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Hi, First of all, sorry for not commenting on this earlier. I only became aware of this PEP yesterday. I like the general idea of adding a marker to show that a boolean function narrows the type of one (or more?) of its arguments. However, the suggested approach seems clunky and impairs

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

I think the use case (for x.is_foo()) is rare. And instead of writing x.is_foo(x), if you make the guard a function you can write is_foo(x). On Thu, Feb 11, 2021 at 6:51 PM Sebastian Kreft wrote: > I still think that we should reconsider deferring what happens to class > and instance methods. >

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

I still think that we should reconsider deferring what happens to class and instance methods. The arguments given in https://www.python.org/dev/peps/pep-0647/#id13 seem insufficient, specially considering than the workaround provided is quite awkward. The author suggests to write def

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

It means "I can't prove it matches". This should be clear from the spec already (it's an important point actually, since it means type checkers cannot narrow in an else clause). So please don't file a PR to "add" this. On Thu, Feb 11, 2021 at 11:49 AM Jim J. Jewett wrote: > If a TypeGuard

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

If a TypeGuard returns false, does that mean "it doesn't match", or just "I can't prove it matches, but it still might"? That seems relevant to the else clause ... and seems to have changed since the last version I looked at. -jJ ___ Python-Dev

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Thu, Feb 11, 2021 at 12:00 AM Jim J. Jewett wrote: > (1) Is it really a TypeGuard, or more of a TypeAssertion? > It's a query, not an assertion. The same concept is called type guard in TypeScript. > (2) Does this push too hard on "annotations only have one meaning"? If > it has to

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

(1) Is it really a TypeGuard, or more of a TypeAssertion? (2) Does this push too hard on "annotations only have one meaning"? If it has to imported from typing, then probably not, but I think that is worth adding to the PEP. (3) Why can't the falsey case of an Optional String narrow to a set

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

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