I have a preference for having the defaults live close to the class. TypeVar scoping and binding is kind of confusing as is.
Completely agree on this point, it's really unfortunate that 637 was rejected. I've updated the draft to add a note about how some metaclasses/supertypes might already consume a parameter with the same name as the TypeVar.
It might be worth spelling out the rules for generic subclasses of generic classes that both have defaulted TypeVars are.
Good idea, done.
It'd also be good to write up some more real-world-code places where this would be useful.
I've added the both the projects from Mehdi2277 and also discord.py which is where the Context example is from.
To what extent would we still want this if we had a commonly used `GenIter = Generator[T, None, None]` generic type alias in typing.py?
Whilst Generator is a compelling use case for this it's certainly not the only place this comes up. Adding type aliases for all of these cases would be annoying and potentially error prone. As others have pointed out it means creating intermediary classes which makes code more confusing to read. Not only that there are also cases that currently can't be supported without defaults like Context where there would have to be two different exported classes for it to work (e.g. BotContext and Context[BotT]) where users could be confused as when they should use one over the other.