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

Class format of TypedDict does not produce proper coverage #17477

Closed
sshishov opened this issue Jul 3, 2024 · 1 comment · Fixed by #17495
Closed

Class format of TypedDict does not produce proper coverage #17477

sshishov opened this issue Jul 3, 2024 · 1 comment · Fixed by #17495
Labels
bug mypy got something wrong

Comments

@sshishov
Copy link

sshishov commented Jul 3, 2024

Bug Report

We are using TypedDict to add the proper coverage and proper types for the codebase where the dictionary with pre-defined keys is used. This should solve the problem, add the proper typing everywhere where this dictionary is used and also increase the total coverage of codebase.

Unfortunately when we are using extensively TypeDicts, we have noticed that the coverage stays the same after applying to the code.

The problem is with the coverage of TypedDict itself, even if it has all the types and values specified, mypy somehow flag it as Any Types on this line

NOTE: At the same time if we convert everything to inline type, then the coverage will be proper 100%.

To Reproduce

from __future__ import annotations

__all__ = ['ChannelTypedDict']

import typing as t


class _RecipientTypedDict(t.TypedDict):
    to: list[str]
    cc: list[str]
    bcc: list[str]


class _DataTypedDict(t.TypedDict):
    recipients: _RecipientTypedDict
    subject: str
    message: str


class ChannelTypedDict(t.TypedDict):
    medium: t.Literal['email']
    data: _DataTypedDict

Expected Behavior

The file with TypedDict definitions should be covered accordingly (in most cases it should have 100% coverage)

Actual Behavior

The file containing TypedDict usually has 50% coverage or around (usually we put types outside of main codebase)
Screenshot 2024-07-04 at 01 14 41Screenshot 2024-07-04 at 01 25 52

Your Environment

  • Mypy version used: mypy 1.10.1 (compiled: no)
  • Mypy command-line flags: --cache-fine-grained (as we are running it with dmypy)
  • Mypy configuration options from mypy.ini (and other config files):
txt_report = "src/mypy-reports"
html_report = "src/mypy-reports"
plugins = [
    "mypy_django_plugin.main",
    "mypy_drf_plugin.main",
    "pydantic.mypy",
]
strict = true
warn_unreachable = true
ignore_missing_imports = true
  • Python version used: Python 3.11.9
@sshishov
Copy link
Author

sshishov commented Jul 7, 2024

Hi @ilevkivskyi , if you would tell me which version of mypy the issue is fixed, then I could validate the diff if it is properly counted or not.

JukkaL pushed a commit that referenced this issue Jul 18, 2024
Fixes #10007
Fixes #17477

This fixes the crash as proposed in
#13732, but also fixes some
inconsistencies in `Any` types exposed by the fix.

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant