This is invalid according to the specification, which says you can only put it in Generic or Protocol. I was actually going to ask whether this should be allowed.

Ah that's good to know. I can see how relaxing that restriction can be desirable, but I guess that that's out of scope here.

Is it a relaxing? This syntax is definitely legal right now without the +. If you allow it with your new syntax, you'll have to decide what it means. For example, maybe it should be possible to have an invariant subclass of a covariant class.

Actually, thinking about it a little more I believe you should allow this, because invariant subclasses of covariant classes are commonplace. My suggestion would be that you have to specify the + again for every subclass, and if there's no + the subclass is invariant.

For example, we have this in the standard library:

class AbstractSet(Generic[+T]): ...  # covariant

class set(Sequence[T]): ...  # invariant

class frozenset(Sequence[+T]): ... # covariant

To express that, we need what I suggested above.

I also agree with Jelle here, I think it should be allowed anywhere the the old forms are allowed.
On another note typing.AbstractSet is deprecated in favour of collections.abc.Set, so it might be a good idea to change that.

Another edge case is this:

class WhatIsMyVariance(Generic[+T], Sequence[-T]): ...

That should probably be disallowed, but this should be spelled out.

I agree with your suggestion @JelleZijlstra . But I think that In your example set and frozenset also need to subclass Generic, i.e.

class set(Sequence[T], Generic[T]): ...  # invariant

class frozenset(Sequence[T], Generic[+T]): ... # covariant

Then the restriction that +T and -T can only be used within the type parameter list of Generic and Protocol still holds. If you were to instead write class frozenset(Sequence[+T], Generic[+T]): ..., to me it looks as if Sequence itself is marked as covariant under T, whereas the covariance only applies to the specific definition of frozenset; the variance information does not need to be passed to the Sequence superclass.
This also avoids the possibility for edge cases, like in WhatIsMyVariance.

That's not how things currently work, though: writing class set(Sequence[T]): is legal and accepted by typecheckers.

Ah I see, somehow I thought that in that case you couldn't do e.g. spam: set[str], and that it required an explicit Generic as additional superclass.

Anyway, I now indeed see how this behavior has to be explicitly defined. Requiring the same variance for the same type variable in the same generic class should do the trick. So no mixing; only allow e.g.

• class LinkedList(Iterable[T], Container[T]): ...
• class LinkedList(Iterable[+T], Container[+T]): ...
• class LinkedList(Iterable[-T], Container[-T]): ...

This could be checked within typing.Generic.__init_subclass__.