[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 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 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

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

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

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

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: Deferred Evaluation Of Annotations Using Descriptors

> How about having a pseudo-module called __typing__ that is > ignored by the compiler: > > from __typing__ import ... > > would be compiled to a no-op, but recognised by type checkers. If you want to do run-time typing stuff, you would use There is already a way of doing that: `if

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

By the way, without adding an other constant, `__debug__` can also be used. It discards runtime overhead when it matters, in optimized mode. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

[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] PEP 597 bikeshedding: envvar / option name.

I am updating PEP 597 to include discussions in the thread. Before finishing the PEP, I need to decide the option name. I used PYTHONWARNDEFAULTENCODING (envvar name) / warn_default_encoding (-X option and sys.flags name) before, but it seems too long and hard to type, easy to misspell.

[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 597 bikeshedding: envvar / option name.

Let the bikeshedding begin. How about with the underscores in place? More readable to my eyes. On Mon, 2021-02-15 at 14:28 +0900, Inada Naoki wrote: > I am updating PEP 597 to include discussions in the thread. > Before finishing the PEP, I need to decide the option name. > > I used

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

I see plenty of envvars with similarly long names at https://docs.python.org/3/using/cmdline.html . So your initial name "PYTHONWARNDEFAULTENCODING" LGTM. The first intuitive choice is often the right one ('cuz it's, well, intuitive). On 15.02.2021 8:28, Inada Naoki wrote: I am updating PEP

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez wrote: > > > How about having a pseudo-module called __typing__ that is > > ignored by the compiler: > > > > from __typing__ import ... > > > > would be compiled to a no-op, but recognised by type checkers. > > If you want to do run-time typing stuff,