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

False-positive errors for attrs - wrong types for default argument? #6207

Closed
olivercoleman-switchdin opened this issue Oct 20, 2023 · 4 comments
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working

Comments

@olivercoleman-switchdin

Not sure if this belongs here, but I'm getting erroneous type errors for the attrs module.

Field definitions like this:

from attrs import field, frozen, validators
@frozen
class Control:
    control_priority: int = field(validator=validators.instance_of(int), default=10)

Give errors like this:

control_definitions.py
  control_definitions.py:40:29 - error: No overloads for "field" match the provided arguments (reportGeneralTypeIssues)
  control_definitions.py:40:102 - error: Argument of type "Literal[10]" cannot be assigned to parameter "default" of type "None" in function "field"
    Type cannot be assigned to type "None" (reportGeneralTypeIssues)

Removing either the validator or the default argument to field make the error go away.

VS Code extension or command-line
I get the same error running PyRight in:

  • VS Code via Pylance v2023.10.30 extension
  • Pants pyright backend running PyRight v1.1.332
@olivercoleman-switchdin olivercoleman-switchdin added the bug Something isn't working label Oct 20, 2023
@erictraut
Copy link
Collaborator

Thanks, I'm able to repro the problem and will investigate further. Here's a simplified example that doesn't rely on attrs.

from typing import Any, Callable, Generic, TypeVar

_T = TypeVar("_T")

class Attribute(Generic[_T]):
    pass

_ValidatorType = Callable[[Any, Attribute[_T], _T], Any]

def field(*, default: _T, validator: _ValidatorType[_T]) -> _T:
    ...

def instance_of(type: type[_T]) -> _ValidatorType[_T]:
    ...

field(validator=instance_of(int), default=10)

@cdce8p
Copy link
Contributor

cdce8p commented May 8, 2024

Just encountered a similar issue, but with Literal and str. Maybe that helps with debugging.

from typing import Container, Generic, TypeVar, Callable, Any
_T = TypeVar("_T")

class Attribute(Generic[_T]): ...
_ValidatorType = Callable[[Any, Attribute[_T], _T], Any]

def field(default: _T, validator: _ValidatorType[_T]) -> _T: ...

def in_(options: Container[_T]) -> _ValidatorType[_T]: ...


s: list[str] = ["normal", "system"]
field("normal", in_(s))
  test.py:13:17 - error: Argument of type "(Any, Attribute[str], str) -> Any" cannot be assigned to parameter "validator" of type "_ValidatorType[_T@field]" in function "field"
    Type "(Any, Attribute[str], str) -> Any" is incompatible with type "_ValidatorType[_T@field]"
      Parameter 2: type "Attribute[_T@field]" is incompatible with type "Attribute[str]"
        "Attribute[Literal['normal']]" is incompatible with "Attribute[str]"
          Type parameter "_T@Attribute" is invariant, but "Literal['normal']" is not the same as "str" (reportArgumentType)

erictraut added a commit that referenced this issue Jun 2, 2024
…a generic function that involves a type variable used in both a covariant and contravariant (or invariant) position and both literal and non-literal types are involved. This addresses part of #6207.
erictraut added a commit that referenced this issue Jun 2, 2024
…a generic function that involves a type variable used in both a covariant and contravariant (or invariant) position and both literal and non-literal types are involved. This addresses part of #6207. (#8049)
@erictraut
Copy link
Collaborator

I've fixed the bug associated with the original bug report. The other bug reported by @cdce8p is actually unrelated, so I've opened a separate issue (#8049) to track that one. The fix for the bug reported by @olivercoleman-switchdin will be included in the next release of pyright.

@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Jun 2, 2024
@erictraut
Copy link
Collaborator

This is addressed in pyright 1.1.366.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants