I don't think we should promote the use of "bare" generic types — those with no type arguments. That's typically indicative of an error on the programmer's part. Pyright accepts them, but it flags it as an error when "strict" mode is enabled. This check has been really useful in helping developers to fix problems in their code, and I don't want to water it down. So I'm not in favor of saying that `Tensor` is the only legitimate way to specify "a `Tensor` whose type arguments can be anything". If we think that concept is needed, then we should support `Tensor[Any, ...]`. As I said, adding support for open-ended tuples will add yet more complexity to the specification and implementation of this PEP, but maybe it's required to meet all of the intended use cases.
Agreed. I think they are mostly a legacy feature.
I just realized there's a situation where bare generic types are important: when evolving a codebase, making certain types that weren't generic before generic. An real-world example is the stdlib Queue type -- this started its life as a non-generic class (in typeshed) and at some point it was made generic. During the time it was non-generic, user code was annotated with things like `(q: Queue)`, and it would be a problem to fault all that code immediately as being non-compliant. So the interpretation of this as `Queue[Any]` makes sense. (Of course a flag exists to make this an error, for users who want to update all their code to declare the item type of their queues.)
So it's not that bare generics themselves are a legacy feature -- but the feature is primarily important for situations where legacy code is being checked.