Should `collections.abc.Container` be generic?

[alanhdu]

This is more of a question, but I am a bit confused about the current definition of Container. Right now, it looks like it is

typeshed/stdlib/typing.pyi

Lines 643 to 647 in a3568ac

	@runtime_checkable
	class Container(Protocol[_T_co]):
	# This is generic more on vibes than anything else
	@abstractmethod
	def __contains__(self, x: object, /) -> bool: ...

This strikes me as an odd definition though: it has a generic parameter (that AFAIK is totally unused), and requires that __contains__ always takes an object type. I feel like it would make sense to either:

1. Make Container not generic (since AFAICT Container[str] vs Container[int] has no actual meaning)
2. Make the type annotation on def __contains__(self, x: _T_co, /) -> bool: ... so that the generic parameter is actually used.

Naively, option 2 seems to be more useful (since you can always have Container[object] if you want) but perhaps I am missing something?

[srittau]

There was some discussion about this in #8785. Basically, we can't change it now, since it would break too much code. It's also nice to be able to write Container[str] just to mark what kind of items are expected to be in the container. And finally, we might be able to use a tighter type in the future, see for example python/typing#2154.

[randolf-scholz]

Is it clear that changing it would break stuff? It seems that quite a lot of people have to use type: ignore because of this:

https://github.com/search?q=%2Fdef+__contains__%5C%28self%2C+%5Cw%2B%3A+%5Cw%2B%5C%29+-%3E+%5Cw%2B%3A%5Cx20%2B%5C%23+type%3A+ignore%2F+language%3APython+&type=code

[randolf-scholz]

The problem seems more that a covariant TypeVar was used, when really it should be a contravariant one, and it is used like so in subclasses:

@runtime_checkable
class Collection(Iterable[_T_co], Container[_T_co], Protocol[_T_co]):
    # Implement Sized (but don't have it as a base class).
    @abstractmethod
    def __len__(self) -> int: ...

It may be fixable by replacing object with Any, then implementers can specify what types __contains__ can be used with without triggering override errors.

[randolf-scholz]

@srittau the results of #15320 seem like a decent improvement.