Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect "TypeVar bound type cannot be generic" in class definition #3497

Closed
christoph-blessing opened this issue May 23, 2022 · 2 comments
Closed
Labels
as designed Not a bug, working as intended

Comments

@christoph-blessing
Copy link

Describe the bug

Creating a type variable that uses another type variable in its bound type creates an error even if the bound type is not generic within the scope of the type variable.

Sidenote: Not sure if this is another bug but I have set typeCheckingMode to "off" and I am still seeing this error.

To Reproduce

from abc import ABC
from typing import Generic, TypeVar

R = TypeVar("R", bound="AbstractRepository")


class AbstractRepository(ABC):
    pass


class AbstractUnitOfWork(ABC, Generic[R]):
    repo: R
    T = TypeVar("T", bound="AbstractUnitOfWork[R]")

    def commit(self: T) -> T:
        return self

I get an error saying "TypeVar bound type cannot be generic" when defining T even though AbstractUnitOfWork[R] is not a generic type in this context.

Expected behavior
No error.

VS Code extension or command-line
I am running Pyright within Neovim. The version is 1.1.248

@erictraut
Copy link
Collaborator

The error is correct. Bound types cannot be generic. They must be concrete. There has been talk of supporting "higher-kinded types" (HKTs) within the Python type system, which would add support for this. But so far, these discussions have not led to any proposals among the type community.

@erictraut erictraut added the as designed Not a bug, working as intended label May 23, 2022
@christoph-blessing
Copy link
Author

Okay, I was just confused because mypy does not report this as an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
as designed Not a bug, working as intended
Projects
None yet
Development

No branches or pull requests

2 participants