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