Skip to content

TypedDict as default_factory in dataclasses is not inferred correctly #5723

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

Closed
iddan opened this issue Oct 3, 2018 · 2 comments · Fixed by #19254
Closed

TypedDict as default_factory in dataclasses is not inferred correctly #5723

iddan opened this issue Oct 3, 2018 · 2 comments · Fixed by #19254
Assignees
Labels

Comments

@iddan
Copy link

iddan commented Oct 3, 2018

  • Are you reporting a bug, or opening a feature request? bug
  • Please insert below the code you are checking with mypy,
    or a mock-up repro if the source is private. We would appreciate
    if you try to simplify your case to a minimal repro.
from dataclasses import dataclass, field
from mypy_extensions import TypedDict

class Person(TypedDict, total=False):
    name: str

@dataclass
class Job:
    person: Person = field(default_factory=Person)
  • What is the actual behavior/output?
main.py:9: error: Incompatible types in assignment (expression has type "main.Person", variable has type "Person")
  • What is the behavior/output you expect? To pass
  • What are the versions of mypy and Python you are using? latest
    Do you see the same issue after installing mypy from Git master? yes
  • What are the mypy flags you are using? (For example --strict-optional) none
@iddan iddan changed the title TypedDict as default_factory in dataclasses are not inferred correctly TypedDict as default_factory in dataclasses is not inferred correctly Oct 3, 2018
@ilevkivskyi
Copy link
Member

This is actually not specific to dataclasses. It looks like typed dict class objects are never analyzed properly. There is a hack in visit_call_expr in type checker, that checks them specially, but if they appear in any other context, the corresponding CallableType is not created correctly.

@tsangwpx
Copy link

tsangwpx commented Nov 4, 2023

In mypy 1.6.1, the output is

error: Argument "default_factory" to "field" has incompatible type "Type[Person]"; expected "Callable[[], Person]"  [arg-type]

workaround:

@dataclass
class Job:
    person: Person = field(default_factory=lambda: Person())

pull bot pushed a commit to Dareh123/mypy that referenced this issue Jun 9, 2025
Fixes python#3832
Fixes python#5723
Fixes python#17174
Improves python#7217

This is a sixth "major" PR toward
python#7724. Previously access to
"static" attributes (like type aliases, class objects) was duplicated in
four places:
* In `analyze_ref_expr()`
* In `determine_type_of_member()` (for modules as subtypes of protocols)
* In instance attribute access logic
* In class attribute logic

Most of these were somewhat incomplete and/or inconsistent, this PR
unifies all four (there is still tiny duplication because I decided to
limit the number of deferrals, i.e. preserve the existing logic in this
respect). Some notable things that are not pure refactoring:
* Previously we disabled access to type variables as class attributes.
This was inconsistent with plain references and instance attributes that
just return `Instance("typing.TypeVar")`.
* Instance access plugins were only applied on `TypeInfo`s and
`TypeAlias`es, now they are applied always.
* Previously arguments kinds were sometimes not correct for TypedDict
class objects with non-required keys.
* I tweaked `TypeOfAny` in couple places to be more logical.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants