Skip to content

Unused function arguments marked with underscore _ are required to have type annotation #18911

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

Open
pktiuk opened this issue Apr 11, 2025 · 1 comment

Comments

@pktiuk
Copy link

pktiuk commented Apr 11, 2025

Bug Report

Method in my class (a wrapper for mqtt library) is missing a type annotation for argument marked as unused in handler no-untyped-def

To Reproduce

class MQTTWrapper:
    @staticmethod
    def _on_connect(
        client: Client,
        userdata: "MQTTClient",
        flags: ConnectFlags,
        reason_code: paho.mqtt.reasoncodes.ReasonCode,
        _,
    ) -> None:
        pass

Expected Behavior

Annotating unused arguments does not seem to make sense.

Actual Behavior

src/mqtt.py:95: error: Function is missing a type annotation for one or more arguments  [no-untyped-def]
        def _on_connect(

Your Environment

  • Mypy version used: mypy 1.15.0 (compiled: yes)
  • Mypy command-line flags:
  • Mypy configuration options from mypy.ini (and other config files):

Part of pyproject.toml

[tool.mypy]
# mypy configuration: https://mypy.readthedocs.io/en/stable/config_file.html#example-pyproject-toml
# mypy settings documentation: https://mypy.readthedocs.io/en/stable/config_file.html#confval-follow_untyped_imports
follow_untyped_imports = true
strict = true # enable --strict before releasing production ready code
exclude = '(tests/.*|debug_scripts/.*)'
  • Python version used:3.12.3
@pktiuk pktiuk added the bug mypy got something wrong label Apr 11, 2025
@sterliakov sterliakov added feature topic-usability and removed bug mypy got something wrong labels Apr 11, 2025
@sterliakov
Copy link
Collaborator

This is not a deficiency in mypy, _ variable is not special in typing contexts.

I'd recommend annotating _: object explicitly. I see some merit in ignoring missing type hints on _ params, but suspect it's a rare case that doesn't warrant additional effort, especially given that the "principled" approach of annotating as object is an acceptable workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants