8000 The base class is erroneously inferred for TypeVar constrained types · Issue #16051 · python/mypy · GitHub
[go: up one dir, main page]
Skip to content

The base class is erroneously inferred for TypeVar constrained types #16051

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.

Sign up for GitHub

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

Jump to bottom
Closed
gh-andre opened this issue Sep 5, 2023 · 4 comments
Closed

The base class is erroneously inferred for TypeVar constrained types #16051

gh-andre opened this issue Sep 5, 2023 · 4 comments
Labels
bug mypy got something wrong

Comments

@gh-andre
Copy link
gh-andre commented Sep 5, 2023

Bug Report

When a generic type defined via TypeVar is used with constrained types, a base class for those types is computed and errors are reported against that base class.

To Reproduce

In this example, get() uses some internal logic to select a constructor, which is either D1 or D2, and add() constructs the specified instance, performs some work with it and returns it to the caller.

from typing import TypeVar
from random import random 

class B: ...

class D1(B):
    def __repr__(self)->str: return "D1 class"
    
class D2(B):
    def __repr__(self)->str: return "D2 class"
    
Q = TypeVar("Q", D1, D2)     # triggers error 1, 2
#Q = TypeVar("Q", bound=B)   # triggers error 2
#Q = TypeVar("Q")            # triggers error 2

def add(c: type[Q])->Q:
    return c()

def get() -> type[D1]|type[D2]:
    return D1 if random() > 0.5 else D2

# [1] error: Value of type variable "Q" of "add" cannot be "B"  [type-var]
# [2] error: Incompatible types in assignment (expression has type "B", variable has type "D1 | D2")
w: D1|D2 = add(get())

print(w)

Expected Behavior

No errors should be reported because all referenced types align against one another and the base class B plays no role in this code. Moreover, if B is removed as a base class of D1 and D2, the errors are still reported, but against object instead of B.

I expect TypeVar with this constraint to behave as if add() is defined as below, which reports no errors.

def add(c: type[D1]|type[D2])->D1|D2:
    return c()

Actual Behavior

main.py:24: error: Value of type variable "Q" of "add" cannot be "B" [type-var]
main.py:24: error: Incompatible types in assignment (expression has type "B", variable has type "D1 | D2") [assignment]

Your Environment

  • Mypy version used: 1.5.1
  • Mypy command-line flags: --strict --check-untyped-defs --strict-equality --warn-redundant-casts --warn-incomplete-stub --warn-unreachable --install-types --non-interactive
  • Mypy configuration options from mypy.ini (and other config files): N/A (none)
  • Python version used: 3.10
@gh-andre gh-andre added the bug mypy got something wrong label Sep 5, 2023
@erictraut
Copy link

I think mypy is correct in generating an error with the constrained TypeVar. You've indicated that the TypeVar Q must be constrained to one of two types: D1 or D2. The type D1 | D2 is not compatible with either of these constraints. If you change the TypeVar definition to Q = TypeVar("Q", D1, D2, D1 | D2), then the constraint can be met. Mypy and pyright are in agreement here.

The other two cases (where Q is a regular TypeVar with or without an upper bound) should work, but you're running into a limitation with mypy's constraint solver. It uses a join operator rather than a union when solving constraints. The "join" of D1 and D2 is B. The use of "join" is the underlying cause of numerous issues in mypy.

@gh-andre
Copy link
Author
gh-andre commented Sep 5, 2023

@erictraut Thanks for the insights.

Well, TypeVar("Q", D1, D2, D1 | D2) is really a work-around, same as using D1|D2 instead of TypeVar in my original example, which one would do just to satisfy the type checker.

In practical terms, it's really this one that matters (even though it's not as good a reproduction case because it introduces explicit B):

Q = TypeVar("Q", bound=B)

, because listing all possible types is counterproductive. For example, consider that B is something like ServiceType and Q is a generic type for a dozen of app services that can be added and activated in a generic way. That list would quickly get out of hand.

The docs for TypeVar do specify that the most derived class is considered when bound= is used with a base class or even a union (i.e. bound=X|Y), so falling back to the base type here does sound like the bug you mentioned - join-vs-union.

Also, given that Pyright handles bound=B as a union, that explains why I don't see this error in Visual Studio and it only pops up in my CI builds, which use mypy.

@ilevkivskyi
Copy link
Member

The options 2 and 3 work now. The option 1 (type variable with constraints) doesn't work, but we have #1533 to track that kind of union math.

@gh-andre
Copy link
Author

@ilevkivskyi Thank you for fixing these two cases. It does make sense to track the constraint/union case as a separate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug mypy got something wrong
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@erictraut @gh-andre @ilevkivskyi
0