[Python-Dev] Re: Relaxing the annotation syntax

What about creating a new syntax for annotating metadata? For example, `type_hint :: metadata` could be equivalent to `Annotated[type_hint, "metadata"]`, and if we wanted type guards to look like TypeScript they could look like this: ``` def is_str_list(val: List[object]) -> bool :: is List

[Python-Dev] Re: Relaxing the annotation syntax

On 16 Apr 2021, at 19:38, Jelle Zijlstra wrote: El vie, 16 abr 2021 a las 10:01, Walter Dörwald () escribió: On 16 Apr 2021, at 16:59, Guido van Rossum wrote: If you look deeper, the real complaints are all about the backwards incompatibility when it comes to locally-scoped types in annotati

[Python-Dev] Re: Relaxing the annotation syntax

Hm, I was specifically thinking of things that introduce new keywords. For example, TypeScript adds unary operators 'infer' and 'keyof'. It would be rather difficult to have to define those as soft keywords throughout the language. (We couldn't just make them unary keywords, since 'infer (x)' shoul

[Python-Dev] Re: Relaxing the annotation syntax

On Mon, 12 Apr 2021, 1:48 pm Guido van Rossum, wrote: > > At the very least I recommend that the SC take this into account when they > consider PEP 649. Accepting it has some nice benefits when it comes to the > scoping rules for annotations -- but it would forever close the door for > the "relax

[Python-Dev] Re: Relaxing the annotation syntax

El vie, 16 abr 2021 a las 10:01, Walter Dörwald () escribió: > On 16 Apr 2021, at 16:59, Guido van Rossum wrote: > > If you look deeper, the real complaints are all about the backwards > incompatibility when it comes to locally-scoped types in annotations. I.e. > > def test(): > class C: ... > def

[Python-Dev] Re: Relaxing the annotation syntax

On 16 Apr 2021, at 16:59, Guido van Rossum wrote: If you look deeper, the real complaints are all about the backwards incompatibility when it comes to locally-scoped types in annotations. I.e. def test(): class C: ... def func(arg: C): ... return func typing.get_type_hints(test()) # r

[Python-Dev] Re: Relaxing the annotation syntax

On Fri, Apr 16, 2021 at 1:51 AM Sebastian Rittau wrote: > I am strongly in favor of diverging type annotation syntax from Python > syntax. Currently, type annotations are a very useful tool, but often > clunky to use. Enhancements have been made, but design space is limited > when working within

[Python-Dev] Re: Relaxing the annotation syntax

If you look deeper, the real complaints are all about the backwards incompatibility when it comes to locally-scoped types in annotations. I.e. def test(): class C: ... def func(arg: C): ... return func typing.get_type_hints(test()) # raises NameError: name 'C' is not defined And that is a

[Python-Dev] Re: Relaxing the annotation syntax

On Sun, Apr 11, 2021 at 1:31 PM Barry Warsaw > wrote: [snip] This is something the SC has been musing about, but as it’s not a fully formed idea, I’m a little hesitant to bring it up.  That said, it’s somewhat relevant: We wonder if it may be time to in a

[Python-Dev] Re: Relaxing the annotation syntax

On Sun, Apr 11, 2021 at 9:41 PM Paul Bryan wrote: > I'm in favour of the approach proposed in PEP 649. > > Movie trailer: "In a world where annotations are arbitrary non-Python > syntax..." > > It seems to me we could always have annotations evaluate to Python > expressions **and* *support any ar

[Python-Dev] Re: Relaxing the annotation syntax

I'm in favour of the approach proposed in PEP 649. Movie trailer: "In a world where annotations are arbitrary non-Python syntax..." It seems to me we could always have annotations evaluate to Python expressions *and* support any arbitrary syntax (e.g. through Annotated[...] or similar mechanism).