Seems like another use case for defaulted generics.

For now, the best we could do is to use Any to prevent false positives? But in this particular case, for now, I believe we should keep the stubs as is, and rely on users overriding these methods to use # type: ignore.

How would others define an interface with an opaque state that could be emitted/passed back? Or is that the point of "defaulted generics" and you want to preserve specific type checking for the standard library implementation until that arrives?

Just curious, but if the state is supposed to be opaque (I'm assuming even for the standard library), why preserve type checking around implementation details that leave and return via getstate/setstate? Aren't those properly accounted for inside the implementation/tests rather than public interfaces?

An opaque state could be defined in several ways: Either using the concrete type as done here. But a better way would probably be to use NewType, which forces the opaque type to match, without necessarily revealing its internals. This doesn't help when overriding the class, though.

Right, so why not strive to keep implementation typing separate from interface typing?

from collections.abc import Mapping as MappingC
from typing import Dict, Mapping, NewType, Protocol

_OpaqueT = NewType("_OpaqueT", object)

class Foo(Protocol):
  def getblob(self) -> _OpaqueT:
    ...
  def setblob(self, blob: _OpaqueT) -> None:
    ...

class FooImpl(Foo):
  def __init__(self):
    self._blob: Dict = {}
  @property
  def foo_impl_blob(self) -> Mapping:
    return self._blob
  def getblob(self) -> _OpaqueT:
    return _OpaqueT(self._blob)
  def setblob(self, blob: _OpaqueT) -> None:
    assert isinstance(blob, MappingC)
    self._blob = dict(blob)

foo = FooImpl()
blob: _OpaqueT = foo.getblob()
assert "missing" not in blob  # Unsupported right operand type for in ("_OpaqueT") 🙌 🎉
foo.setblob(blob)
assert "missing" not in foo.foo_impl_blob  # totally cool

Or are you saying that the current implementation of random.Random leaks into the interface and implementation maintainers depend on those leaks, so there's little typeshed can do on the side to paper over that dysfunction?

As this is not something we can express in typeshed right now, but could be improved if typing improves, I've marked this as inexpressable and am closing this per our policy. This can be revisited if typing improves.