Thanks to everyone who attended today's meetup. You can check out the recording, chat, and slides in the running Google doc [1]. Thanks to Sebastian for presenting about TypeVar syntax, and thanks to the core Python developers who joined this meeting.

Meeting notes:

+ Context: In the Typing Summit panel [2] during PyCon 2022, we had asked Steering Council members (Thomas Wouters and Pablo Galindo Salgado) about future syntax proposals for typing. They replied that "The more constrained the syntax is, the less resistance there will be from the community." and "We need to consider that you can put type annotation syntax into a cast as an expression and it would work, so syntax changes are not just affecting types".

So, we decided to dedicate the meetup to a discussion about TypeVar syntax, since it is a constrained syntax that will (mostly) affect the syntax of statements rather than expressions.

+ Sebastian mentioned three possible syntaxes for declaring a TypeVar:
  (a) angular brackets `def foo<T>(x: T) -> T:`
  (b) square brackets `def foo[T](x: T) -> T:`
  (c) new scope syntax: such as, `let T = TypeVar("T") in def foo[T](x: T) -> T:` (Jelle had proposed this earlier)

  Other proposals from the audience:
  (d) decorator syntax
  (e) new delimiter for TypeVar declarations: something different from `<>` and `[]`. Maybe `{}`.

  For more details, see the slides linked in the doc.

+ Sebastian also described the "mini-language" to specify variance, upper bound, etc. The main approaches here were:

  (a) punctuation only (`def foo[T <= int](x: T) -> T`)
  (b) keyword (`def foo[T bound int](x: T) -> T`)
  (c) function-style syntax (`def foo[T (bound=int)](x: T) -> T`)

  The most extensible option is (c). We could add new flags to the TypeVar declaration without having to change the language syntax.

+ Objections:

  (a) Angular brackets could lead to ambiguity with existing `<` and `>`.
  (b) Square brackets could be hard to read given how much they are already used.
  (c) New scope syntax: This could hurt readability if generic classes and methods need to be indented. If we don't indent the statement after `let T = TypeVar("T") in `, it's unclear if T is scoped only to the next statement or to the rest of the file. Most importantly, it is pretty verbose in the current proposal - we have to write what we currently write (`T = TypeVar("T")`) plus `let ... in`. It doesn't seem to be clearly better than the existing syntax.

+ Usability improvements: Eric Traut suggested that "If a TypeVar is associated with only one scope, its variance could be inferred from its usage". That might eliminate the need for special syntax to specify variance.