Generic Self Type

[jboning]

This is a followup issue to #1212. #2193 enabled method type annotations to refer to the type of self, but (intentionally) didn't address generic classes. In many cases, the self types added there meet the needs of generic classes, but not always.

A motivating example is typeshed's AbstractClass:

class AbstractSet(Sized, Iterable[_T_co], Container[_T_co], Generic[_T_co]):
    def __and__(self, s: AbstractSet[Any]) -> AbstractSet[_T_co]: ...
    def __or__(self, s: AbstractSet[_T]) -> AbstractSet[Union[_T_co, _T]]: ...

With #2193 we can annotate __and__, and it works beautifully:

    def __and__(self: SelfT, s: AbstractSet[Any]) -> SelfT: ...

def f(s, fs):
    # type: (MutableSet[str], FrozenSet[str]) -> None
    reveal_type(s.__and__)  # Revealed type is 'def (typing.AbstractSet[Any]) -> typing.MutableSet[builtins.str]'
    reveal_type(fs.__and__)  # Revealed type is 'def (typing.AbstractSet[Any]) -> typing.FrozenSet[builtins.str]'

But, we don't have the tools to give __or__ a similarly specific type. To do this, we need some way to talk about the "generic" part of the self type.

[JukkaL]

This feels like a duplicate of #2354, but the example raises somewhat different concerns. Maybe we should copy the example to #2354 and close this issue?

[jboning]

Oh, indeed! I failed to find that. I'll do that when I'm at a keyboard later (or feel free to preempt me)

…

On Wed, Dec 7, 2016, 4:59 PM Jukka Lehtosalo ***@***.***> wrote: This feels like a duplicate of #2354 <#2354>, but the example raises somewhat different concerns. Maybe we should copy the example to #2354 <#2354> and close this issue? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2537 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAW9K3YkL4yCrO0NhjvGEIVkm6YfC1Wyks5rF1Z2gaJpZM4LHS79> .