Thanks, Eric, for the talk and your work on the PEP!
As usual, the recording and slides are available in the running Typing Meetup notes doc 
Adding to Eric's notes from the meetup:
+ Eric mentioned that he's explicitly not including syntax for generic Callables in this PEP. That is, we are not looking to have syntax for `Callable[T][[T], T]`, etc.
+ Sebastian: I think when Jukka first suggested the `type` keyword, he had some more examples where such a keyword would be useful.
+ The PEP suggests `T: int` as a replacement for `TypeVar("T", bound=int)`. One concern about the upper-bound syntax is that it might be confusing for users who see `x: int` as a variable annotation elsewhere. That syntax usually means that any value of type compatible with `int` can be assigned to `x`, but that `x` will be seen as having type `int`. That is not the case for `T` with upper bound `int`, since it will be specialized to the specific type that was passed by the user. So, it might be worth having syntax such as `T <: int` or `T extends int`.
+ Regarding extensibility of the TypeVar "mini-language", Eric mentioned that, while it is harder to extend the punctuation syntax, we might get away by adding information within the type annotations that we use for the upper bound, etc.
+ One idea suggested by Kevin was that we allow keyword arguments when specializing types. For example, if we have `GenericParent[T, R]`, we might have `class Base(GenericParent[R, T=int]): ...`. Note that PEP 637 (Support for indexing with keyword arguments)  was rejected . Though, the SC did say, "The strongest argument for the new syntax comes from the typing side of Python", so it might be worth trying again in the future (not in this PEP).
: https://docs.google.com/document/d/17iqV7WWvB0IwA43EPlIqlUS6Xuvk08X3sEudAA-g... : https://peps.python.org/pep-0637 : https://email@example.com/thread/6TAQ2BEVS...
On Tue, Jun 28, 2022 at 3:53 PM Eric Traut firstname.lastname@example.org wrote:
I'd like to thank everyone who attended today's typing meetup and provided feedback on the proposal.
I wasn't able to take notes during the discussion, but here are a few pieces of feedback that I jotted down after the meeting ended. (Pradeep or other attendees, please feel free to add anything that you think is material to the discussion.)
- There seemed to be a general consensus that square bracket notation was
the best option for type parameter declaration.
- There also seemed to be a general consensus that a "punctuation"
approach was best for the TypeVar "mini language" syntax. (Guido wasn't able to attend the meeting, but he mentioned above that he prefers the "function" approach for extensibility. The consensus was that the function approach was too verbose and harder to understand. The punctuation approach is admittedly less extensible, but we have some options since the bound expression is a general value expression, so it could support additional expression forms — including call expressions — without changing the grammar.)
- Sebastian suggested that there might be better alternatives to the colon
token for specifying an upper bound or constraints. Potential replacements include "<" or "<:". (Note: I think I still prefer colon here, but that might be because of familiarity.)
- Several people objected to a compile-time check that prevents a
locally-bound name from overlapping with a type parameter used in a "def", "class" or "type" statement within that same scope. I agree with that feedback, and I've subsequently updated the prototype cpython implementation and the PEP to address this feedback.
I mentioned during the meeting that I need help from authors of runtime type checking libraries to help me understand what techniques they currently rely on — and whether the proposal breaks any key assumptions. Tin (attrs & cattrs) and Jelle (pyanalyze) were present for the discussion, but we'll need to get feedback from others as well.
-- Eric Traut Contributor to Pyright & Pylance Microsoft _______________________________________________ Typing-sig mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: email@example.com