This is not safe, if I continue this example like this I get an error at runtime that is not detected:

classSub(Cov[int]):defnew(self,arg:list[int])->Sub:print(arg[0].to_bytes())returnselfcov_pos:Cov[object]=Sub()cov_pos.new([object()])

On a more general level, how exactly this:

classCov[T]:defget(self)->T: ...defnew[S](self:Cov[S],arg:list[S])->Cov[S]: ...

is different from this

classCov[T]:defget(self)->T: ...defnew(self,arg:list[T])->Cov[T]: ...

? Maybe I am missing something but these two are literally identical in terms of semantics. Can you give an example ofuses ofCov where these two classes behave (or should behave) differently?

? Maybe I am missing something but these two are literally identical in terms of semantics.

I think they are only identical when called as a bound method, but not when called on the class and passingself as a regular argument. Note that my original example in#19439 - which is how I came across this issue -- was in the context of classmethods, and theCov test case was really just breaking this down to the most elementary MWE.

classCov[T]:defget(self)->T: ...defnew[S](self:Cov[S],arg:list[S])->Cov[S]: ...x:Cov[int]Cov[str].new(x, [1,2,3])# OK

whereas

classCov[T]:defget(self)->T: ...defnew(self,arg:list[T])->Cov[T]: ...x:Cov[int]Cov[str].new(x, [1,2,3])# not OK, self must be subtype of Cov[str]

• https://mypy-play.net/?mypy=latest&python=3.12&gist=122e95729e7b7573cdba5ab981a342e3
• https://mypy-play.net/?mypy=latest&python=3.12&gist=bf195658c63c961c3ac5a7539bb35291

Consequently, I'd argue that yourSub example is not a proper subclass ofCov.pyright agrees thatSub.new is does not overrideCov.new in a compatible manner. Code sample inpyright playground

So I'd say this is actually a false negative in mypy.https://mypy-play.net/?mypy=latest&python=3.12&gist=f60a4694098406077af0b8627fc78557

Access on class object is not a good argument. For two reasons:

• First, prohibiting overrides that are incompatible on class object only would prohibita lot of use cases that people expect to be treated as safe. Most notably, overrides involving properties and various custom descriptors will stop working.
• Second, my example doesn't involve or rely on class object access in any way. So it is at least weird to say the unsafety is caused by the class object access incompatibility.

Finally, things likeC[int].method are not really well specified (for good reasons, google type erasure). Support for this was added to mypy only recently, following a popular demand.

Btw#18334 is not a bug, it is a true positive. Coming back to your original issue: the two revealed types here are different (and both IMO correct):

classFoo[T](Sequence[T]):@classmethoddefnew[T2](cls:"type[Foo[T2]]",arg:list[T2])->"Foo[T2]": ...@classmethoddefnew2[T2](cls,arg:list[T2])->"Foo[T2]": ...tfi:type[Foo[int]]reveal_type(tfi.new)# def (arg: builtins.list[builtins.int]) -> tstgrp3.Foo[builtins.int]reveal_type(tfi.new2)# def [T2] (arg: builtins.list[T2`2]) -> tstgrp3.Foo[T2`2]

and this is the reason why a class with the first method is considered invariant. I understand why do you want to have the first one: the body should include something likereturn cls(arg) which would give an error with the second method.

TBH I don't think this is solvable without special-casing alternative constructors somehow. Also it looks like a flaw in PEP 695, there should be a simple way to override inferred variance.

@ilevkivskyi your unsafety example is very similar to what I pointed out before, and the problem is roughly "yes, this is obviously unsafe, but the spec says so". What's the official mypy stance on the spec conformance? I prefer to read the spec as an advice, not a mandatory requirement, but IDK if that matches the project attitude.

If mypy considers spec conformance its goal, then this PR is correct, and a typing-sig discussion is needed to fix this spec unsoundness. If not, this PR makes the state of affairs worse, trading false positives for false negatives.

there should be a simple way to override inferred variance

There is, it's calledtyping.TypeVar. AFAIC this ability was one of the reasons to not even consider deprecating "old-style" generics. I think it's rare enough to not warrant any extra syntax (though I'm a bad person to ask about that, IMO PEP695 should have never been implemented at all), so not a PEP omission.

@sterliakov

I prefer to read the spec as an advice, not a mandatory requirement, but IDK if that matches the project attitude.

Yes, this is the official mypy stance: internal consistency is more important than consistency with the spec.

AFAIC this ability was one of the reasons to not even consider deprecating "old-style" generics

OK, I see :-)

there should be a simple way to override inferred variance.

Feel free to comment or👍 my suggestion for explicit variance spec for PEP695 type hintsin discourse.