Skip to main content

Pyright reportUnknownMemberType in Pyrefly

Pyright's reportUnknownMemberType fires when a member exists but its type cannot be determined. pyrefly init maps it to unknown-attribute-type:

[errors]
unknown-attribute-type = "error"

The Pyrefly kind defaults to ignore, so a project that relied on Pyright's strict unknown-member policy has to enable it explicitly. pyrefly init does that for you when the Pyright config sets the rule.

Unknown is not the same as missing

class Dynamic:
value = some_untyped_factory()

item = Dynamic()
item.value # the member exists, but its type is unknown
item.does_not_exist # the member is missing

Pyrefly reports these as different kinds:

ScenarioPyrefly kind
The attribute exists but its inferred type is unknownunknown-attribute-type
The attribute does not existmissing-attribute
An imported name is absent from a modulemissing-module-attribute
The attribute is implicitly Any-like because it was assigned None or () without an annotationimplicit-any-attribute

Substituting missing-attribute for reportUnknownMemberType changes the policy rather than preserving it.

PyrightPyrefly
reportUnknownMemberTypeunknown-attribute-type
reportUnknownVariableTypeunknown-variable-type
reportUnknownArgumentTypeunknown-argument-type
reportUnknownParameterTypeimplicit-any-parameter
reportUnknownLambdaTypeimplicit-any-lambda

Reduce unknown member types at the source

  • install or improve package stubs;
  • annotate factory return types;
  • annotate class attributes explicitly;
  • avoid replacing resolvable imports with Any;
  • review decorators or framework behavior that generates members dynamically.

If the project previously relied on Pylance- or Pyright-specific behavior for generated members, exercise those frameworks in Pyrefly before weakening the diagnostic. Pyrefly models Pydantic, Django, and attrs directly, so an unknown member on a model or an ORM field is more likely a framework-support gap worth reporting than a reason to disable the rule project-wide.