Skip to content

Mypy Self Checking Should Enable --warn-unreachable #18079

Closed

Description

@davidhalter

Is it intentional that --warn-unreachable is not used while self checking in the CI? (with mypy_self_check.ini)

I have recently realized that this is not turned on and it feels a bit strange. There are about 39 errors when running with --warn-unreachable and it brings up a few questionable things like https://github.com/python/mypy/blob/master/mypy/test/testpep561.py#L180.

@sobolevn told me to create this issue in #18076 (comment)

Activity

  1. added
    refactoringChanging mypy's internals
    and removed
    bugmypy got something wrong
    on Oct 31, 2024
  2. sobolevn commented on Oct 31, 2024

    @sobolevn
    Member

    Please, feel free to send a PR.

  3. AlexWaygood commented on Nov 1, 2024

    @AlexWaygood
    Member

    I tried this in the past and found that it caused too many false-positive errors in the self-check at that point to make it feasible. For example, branches under if sys.platform == "win32" tests were thought to be unreachable if checking with --platform=linux (strictly speaking that's true, but it's very annoying and not at all useful to have that cause the check to fail).

    The reachability heuristics mypy uses may have improved since then, though; it was a while ago that I tried it.

  4. davidhalter commented on Nov 1, 2024

    @davidhalter
    Author

    For example, branches under if sys.platform == "win32" tests were thought to be unreachable if checking with --platform=linux

    I don't think this is the case anymore. I also haven't had any problems with it in my personal projects and going randomly through 8 of the 39 issues raised above, Mypy seems to be correct about all of them except maybe one that is related to mypy_extensions.trait. I'm not sure I have the time right now, but I really believe that this would be worth it.

  5. JelleZijlstra commented on Nov 1, 2024

    @JelleZijlstra
    Member

    I think turning this option on for mypy itself would be a good way to dogfood it and force ourselves to make sure it is reliable.

  6. AlexWaygood commented on Nov 1, 2024

    @AlexWaygood
    Member

    I absolutely agree that this would be worth it if it is possible! I wasn't trying to dissuade anybody, was just giving context on something I previously tried a while back :-)

    And, it may well be that the check has improved significantly since I tried it last!

  7. A5rocks commented on Jan 24, 2025

    @A5rocks
    Collaborator

    I started doing this (as a blocker for another mypy change) and the first 3 errors I had to fix were just #10773... So I think that blocks this. Things like this:

    def parse_gray_color(cup: bytes) -> str:
        """Reproduce a gray color in ANSI escape sequence"""
        if sys.platform == "win32":
            assert False, "curses is not available on Windows"
        set_color = "".join([cup[:-1].decode(), "m"])  # E: Statement is unreachable
        gray = curses.tparm(set_color.encode("utf-8"), 1, 9).decode()
        return gray

    (obviously this can be made reachable (use assert sys.platform != "win32", "curses is not available on Windows") but IMO it's better to avoid that churn)


    Nevermind I got confused when thinking about this issue so I'd rather just update these functions that think more.

  8. added a commit that references this issue on Feb 14, 2025
    555bfae
  9. added a commit that references this issue on Feb 24, 2025
    526a8c4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions