Using a ClassVar definition for this facility feels pretty hacky to me. There is no assigned value to this class variable at runtime, so this feels like a misuse of the ClassVar type qualifier. Not surprisingly, when you misuse aspects of the type system, you’ll often find that they don’t work well in certain cases. That’s what we’re seeing here with the use of generics.
When you initially posed this problem, I thought there was a need for a runtime component. That’s why I proposed a magic method. But it now sounds like no runtime component is desired — that this is purely a static analysis mechanism. Do I have that correct? If so, we may want to rethink the approach. Maybe we should explore a class decorator mechanism?
I’m also wondering if we should hold off on defining this mechanism until after we make additional progress on clarifying the use of Annotation for static types. Currently, there are no rules in the typing spec about Annotated metadata, so static type checkers cannot generally reason about metadata. This PEP attempts to define the first aspect of annotated metadata that static type checkers can reason about, but it feels very incomplete. I worry that if we proceed with this PEP, we could regret it once we flesh out more aspects of annotated metadata. Maybe we should try to do something that’s more holistic.
I noticed that you updated the PEP to switch from a function to a ClassVar, but you didn’t incorporate feedback about the name of the attribute. It’s still called __supports_type__ in the latest draft. There was pretty strong feedback that this should be changed to a name that includes annotated within it.
I think for now I’m going to remove pyright’s existing provisional support for this PEP. I’d like to see the idea progress further before I reimplement another variant.