HKT subtype method signature "incompatible with supertype"

Bug report

I’m following your docs for HKTs. Thanks for the new feature btw. I’m seeing type errors that I don’t understand

from __future__ import annotations
from abc import ABC, abstractmethod
from typing import TypeVar, Generic, Mapping, Iterator, Callable
from returns.primitives.hkt import Kind1, kinded, SupportsKind1

T_co = TypeVar("T_co", covariant=True)
U = TypeVar("U")
V = TypeVar("V")
G = TypeVar("G", bound="Grouping")


class Grouping(ABC, Generic[T_co]):
    @kinded
    @abstractmethod
    def map(self: G, f: Callable[[T_co], U]) -> Kind1[G, U]:
        ...

    @kinded
    @abstractmethod
    def zip_with(self: G, other: Kind1[G, U], f: Callable[[T_co, U], V]) -> Kind1[G, V]:
        ...


class One(Grouping[T_co], SupportsKind1["One", T_co]):
    def __init__(self, o: T_co):
        self._o = o

    def get(self) -> T_co:
        return self._o

    def map(self, f: Callable[[T_co], U]) -> One[U]:
        return One(f(self._o))

    def zip_with(self, other: One[U], f: Callable[[T_co, U], V]) -> One[V]:
        return One(f(self.get(), other.get()))

I’m seeing

grouping.py:31: error: Signature of "map" incompatible with supertype "Grouping"
grouping.py:34: error: Signature of "zip_with" incompatible with supertype "Grouping"

Can you help explain what’s wrong? In the docs you use

class Kind(Generic[_InstanceType, _FirstTypeArgType]):
    """Used for HKT emulation."""

whereas I use Kind1. Am I doing that right?

On a separate but related note, I was also seeing, for map signature on Grouping

def map(self: Kind1[G, T_co], f: Callable[[T_co], U]) -> Kind1[G, U]:

the error

grouping.py:15: error: The erased type of self "returns.primitives.hkt.KindN[G`-1, T_co`1, Any, Any]" is not a supertype of its class "grouping.Grouping[T_co`1]"

but it’s not entirely clear to me whether I should use self: G instead, or make Grouping subclass SupportsKind1["Grouping", T_co]

System information

• python version: 3.8
• returns version: 0.15.0
• mypy version: 0.782

[joelberkeley]

ok, thanks. I can then get it to pass using dekind within the method.

A bit of feedback: It would be really nice if there was some way of being able to specify One[U] in the function arguments rather than Kind[One, U], as it’s much more readable and is standard type hint style. I appreciate we can’t do this when One is replaced by a generic type constructor e.g. G, but it would be great if it could be universally possible with concrete container types like One

[sobolevn]

oh ok, why’s that? the return type on the implementations aren’t Kind1, so why is @kinded necessary?

My bad, I am reading this in bed 😆

supertype defines the argument type as “KindN[One[T_co], U, Any, Any]”

Here’s how to fix it: https://github.com/dry-python/returns/blob/master/returns/io.py#L130